DETAILED ACTION
Note
Examiner notes that the specification/abstract/drawings are drawn to a mounting mechanism. It does not correspond to the filed claims.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Specification
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
The abstract of the disclosure is objected to because it does not pertain to the claimed invention. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the claimed monitoring client must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 invokes 112F for “operating system component” and “sandbox component” the specification does not disclose corresponding structure and algorithm for the components. It therefore does not meet the description requirement. For the purposes of Examination, these terms, as used in the art, are used to describe software. These elements are interpreted as software per se.
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 1-10 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.
Claim limitations “operating system component” and “sandbox component” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not describe software and structure corresponding to these elements. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 8-10 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. The claims recite “system for electronic patient care of claim 1” it is unclear which system the claim is referring to as claim 1 is directed to a monitoring client. The dependent claims 9-10 are rejected for the same reasons as claim 8.
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-7 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a monitoring client performing software functions. While the monitoring client is not disclosed in the specification, the broadest reasonable interpretation encompasses software per se, which is not one of the statutory categories.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of pre-AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
Claims 1-3 and 6-8 is/are rejected under pre-AIA 35 U.S.C. 102(b) as being unpatentable over U.S. Patent Application US 2010/0299517 to Jukic et al.
As to claim 1, Jukic discloses a monitoring client comprising:
an operating system component configured to access a hardware resource and/or a software resource (Jukic [0045]-[0046] where “device manager software algorithms may be virtual machines” and “The device managers 110 may be configured to monitor, analyze, convert, filter and/or transform data streams received from the connected devices 120, or receive and generate device specific events, such as alarms, warnings, or maintenance requests.”); and
a sandbox component (Jukic [0045]-[0046] where a sandbox component is a virtual machine) configured to control access to the hardware resource and/or the software resource (Jukic [0045]-[0046] where “device manager software algorithms may be virtual machines” and “The device managers 110 may be configured to monitor, analyze, convert, filter and/or transform data streams received from the connected devices 120, or receive and generate device specific events, such as alarms, warnings, or maintenance requests.”);
wherein the monitoring client is configured for:
identifying a patient-care device (Jukic [0142] see “to establish the RPC channel, the server receives a 4 byte service identification (310) and a client serial number (320) from the client. The server checks to see if the serial number is pre-authorized (330). In the case that the serial number is not pre-authorized, a non-authorized message is sent (331). In response to the non-authorized message, a proxy request may be received at the server (332). After the proxy request is received, or the serial number is authorized, a link control protocol (LCP) connection intention protocol is received (340). The LCP connection intention protocol is followed by a 1024 or 2048 bit RSA encryption key (350). If the encryption key is acknowledged, an RPC channel is established (360).” Where a “remote procedure call (RPC) connection [is] between a server and a network device”); and
executing an application configured for monitoring the patient-care device (Jukic [0045]-[0046] where “device manager software algorithms may be virtual machines” and “The device managers 110 may be configured to monitor, analyze, convert, filter and/or transform data streams received from the connected devices 120, or receive and generate device specific events, such as alarms, warnings, or maintenance requests.” And [0056] “the network system 100 may be a healthcare network and the plurality of devices 120 may be medical devices such as patient monitors, infusion pumps, ventilators, oxygen meters, anesthesia equipment, fetal monitors, heart monitors, electrocardiograph (EKG) machines, magnetic resonance imaging (MRI) machines, X-ray machines, and computed tomography (CT) scanners.”);
wherein said executing is within said sandbox component (Jukic see virtual machines [0045]-[0046]).
As to claim 2, see the discussion of claim 1, additionally, Jukic discloses the monitoring client further configured for controlling the patient-care device (Jukic [0045]-[0046] see “The device managers 110 may be configured to monitor, analyze, convert, filter and/or transform data streams received from the connected devices 120, or receive and generate device specific events, such as alarms, warnings, or maintenance requests.” And [0050] “In another aspect, the visual, auditory, or tactile alarms or warnings may be executed at one or more devices 120.”).
As to claim 3, see the discussion of claim 1, additionally, Jukic discloses the monitoring client wherein the patient-care device is selected from: an infusion pump (Jukic [0056] see ”In one embodiment, the network system 100 may be a healthcare network and the plurality of devices 120 may be medical devices such as patient monitors, infusion pumps, ventilators, oxygen meters, anesthesia equipment, fetal monitors, heart monitors, electrocardiograph (EKG) machines, magnetic resonance imaging (MRI) machines, X-ray machines, and computed tomography (CT) scanners.”).
As to claim 6, see the discussion of claim 1, additionally, Jukic discloses the monitoring client wherein the hardware resource is selected from: a speaker (Jukic [0042]-[0043] see “a device manager 110 may further include one or more additional components (not shown). Such components may include, among others, a display, such as a liquid crystal display (LCD), plasma display, light emitting diode (LED) display, a dot-matrix display, or a seven segment display, an auditory component, such as a speaker, a vibratory component, or a battery power component.”).
As to claim 7, see the discussion of claim 1, additionally, Jukic discloses the monitoring client wherein the software resource is selected from: a software representation of a hardware component (Jukic [0045]-[0046] where “device manager software algorithms may be virtual machines” and “The device managers 110 may be configured to monitor, analyze, convert, filter and/or transform data streams received from the connected devices 120, or receive and generate device specific events, such as alarms, warnings, or maintenance requests.” );
As to claim 8, see the discussion of claim 1, additionally, Jukic discloses the monitoring client further comprising a patient-care device (Jukic [0056] see “the network system 100 may be a healthcare network and the plurality of devices 120 may be medical devices such as patient monitors, infusion pumps, ventilators, oxygen meters, anesthesia equipment, fetal monitors, heart monitors, electrocardiograph (EKG) machines, magnetic resonance imaging (MRI) machines, X-ray machines, and computed tomography (CT) scanners.”).
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4, 5, 9, and 10 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over U.S. Patent Application US 2010/0299517 to Jukic et al. in view of U.S. Patent Application Publication 2010/0292556 to Golden.
As to claim 4, see the discussion of claim 1, additionally, Jukic discloses the monitoring client further configured for:
receiving an identification from the patient-care device (Jukic [0142] see “to establish the RPC channel, the server receives a 4 byte service identification (310) and a client serial number (320) from the client. The server checks to see if the serial number is pre-authorized (330). In the case that the serial number is not pre-authorized, a non-authorized message is sent (331). In response to the non-authorized message, a proxy request may be received at the server (332). After the proxy request is received, or the serial number is authorized, a link control protocol (LCP) connection intention protocol is received (340). The LCP connection intention protocol is followed by a 1024 or 2048 bit RSA encryption key (350). If the encryption key is acknowledged, an RPC channel is established (360).” Where a “remote procedure call (RPC) connection [is] between a server and a network device”).
However, Jukic does not explicitly teach:
downloading the application from a server associated with the identification.
Golden discloses downloading the application from a server associated with the identification (Golden [0134] see “downloading to a user's medical device or user device is typically only done using authentication and user verification to ensure only authorized and appropriate users may download and run the certified medical applications” and [0165] “, a user will be subject to SAS access security procedures to authenticate, authorize and access associated certified medical applications. The desired and approved or authorized application (which may be based on medical provider criteria, insurance company criteria, or other security or verification criteria) may then be directly downloaded, over the air, to the user's device, such as device 210 of FIG. 2A.”).
It would have been obvious to one of ordinary skill in the art at the time of invention to allow a user to download an application associated with an identification as in Golden in the system of Jukic to insure that the appropriate software is utilized for the appropriate medical device.
As to claim 5, see the discussion of claim 1, additionally, Jukic discloses the monitoring client further configured for:
receiving an identification from the patient-care device receiving an identification from the patient-care device (Jukic [0142] see “to establish the RPC channel, the server receives a 4 byte service identification (310) and a client serial number (320) from the client. The server checks to see if the serial number is pre-authorized (330). In the case that the serial number is not pre-authorized, a non-authorized message is sent (331). In response to the non-authorized message, a proxy request may be received at the server (332). After the proxy request is received, or the serial number is authorized, a link control protocol (LCP) connection intention protocol is received (340). The LCP connection intention protocol is followed by a 1024 or 2048 bit RSA encryption key (350). If the encryption key is acknowledged, an RPC channel is established (360).” Where a “remote procedure call (RPC) connection [is] between a server and a network device”).
However, Jukic does not explicitly teach:
updating the application from a server associated with the identification.
Golden discloses updating the application from a server associated with the identification.
(Golden [0134] see “downloading to a user's medical device or user device is typically only done using authentication and user verification to ensure only authorized and appropriate users may download and run the certified medical applications” and [0165] “, a user will be subject to SAS access security procedures to authenticate, authorize and access associated certified medical applications. The desired and approved or authorized application (which may be based on medical provider criteria, insurance company criteria, or other security or verification criteria) may then be directly downloaded, over the air, to the user's device, such as device 210 of FIG. 2A.” see also updated applications [0038] and [0081]).
It would have been obvious to one of ordinary skill in the art at the time of invention to allow a user to update an application associated with an identification as in Golden in the system of Jukic to insure that the appropriate software is utilized for the appropriate medical device.
As to claim 9, see the discussion of claim 8, additionally, Golden discloses the monitoring client wherein said monitoring client is configured for:
communicating with electronic medical records (Golden [0113] see “PHR can store all or parts of the interactions between the user device 310, medical device and/or the service platform. For example, the PHR can augment more common PHR data such as allergies, diseases, etc, by logging items such as continuous glucose sensor information, defibrillator events and alarms, pace maker rhythm setting changes, drug delivery amounts, dates and times.”);
identifying a patient (Golden [0134] see “downloading to a user's medical device or user device is typically only done using authentication and user verification to ensure only authorized and appropriate users may download and run the certified medical applications” and [0165] “, a user will be subject to SAS access security procedures to authenticate, authorize and access associated certified medical applications. The desired and approved or authorized application (which may be based on medical provider criteria, insurance company criteria, or other security or verification criteria) may then be directly downloaded, over the air, to the user's device, such as device 210 of FIG. 2A.” see also updated applications [0038] and [0081]).
downloading a treatment parameter from the electronic medical records (Golden [0113] see “PHR can store all or parts of the interactions between the user device 310, medical device and/or the service platform. For example, the PHR can augment more common PHR data such as allergies, diseases, etc, by logging items such as continuous glucose sensor information, defibrillator events and alarms, pace maker rhythm setting changes, drug delivery amounts, dates and times.”); and
programing the patient-care device with the treatment parameter (Golden [0095] see “As one example associated with a diabetic patient, instead of the patient carrying around Insulet's OmniPod controller device to deliver a bolus or change their basal rate, the patient would be provided with an interface to open an equivalent medical application on their user device 210 (e.g., a mobile device) and perform the same functions without need for the controller.”).
It would have been obvious to one of ordinary skill in the art at the time of invention to allow a user to allow for remote programming of a patient device as in Golden in the system of Jukic to improve the portability of patient care devices by allowing their controls to be emulated on another device.
As to claim 10, see the discussion of claim 9, additionally, Golden discloses the monitoring client wherein said identifying a patient is based on: an identification (Golden [0134] see user authentication).
Conclusion
U.S. Patent Application Publication 2008/0235765 to Shimizu which discusses a virtual machine.
U.S. Patent Application Publication 2009/0184823 to Tessier discusses visualization of infusion pump controls using a virtual machines.
U.S. Patent 10,173,008 to Simpson which discusses virtual machines for infusion pumps and barcodes associated with a particular patient and machine
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Eliza Lam whose telephone number is (571)270-7052. The examiner can normally be reached Monday-Friday 8-4:30PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Peter Choi can be reached at 469-295-9171. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ELIZA A LAM/ Primary Examiner, Art Unit 3681