Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The present Office Action is in response to the Request for Continued Examination dated 22 September 2025.
Request for Continued Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 22 September 2025 has been entered.
DETAILED ACTION
In the amendment filed 22 September 2025:
Claim 1,9,17 are amended
Claim(s) 1-20 are pending
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The Examiner notes that the rejection will reference the translated documents (attached) corresponding to any foreign documents recited in the rejection.
Claims 1-6 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over Rule et al (US Publication No. 20150045641) in view of Rentas et al (US Publication No. 20150051922) in view of Rao et al (US Publication No. 20060265253).
Regarding Claim 1
Rule teaches a server system for processing patient test data from at least one point of care device, the server system comprising:
a test data interface for receiving point of care test data for a patient from at least one point of care device over a communications network [Rule at Para. 0087 teaches one or more components of the monitoring device 102 can communicate with one or more other components of the monitoring device 102 (or with other devices) by communication interface(s) such as, but not limited to, optical interfaces, electrical interfaces, and/or wireless interfaces. These interfaces can be part of a local network, internet, wireless network, or other suitable networks; Rule at Para. 0284 teaches in some embodiments, the computer system 2646 runs optional data analysis software 2648 that organizes and presents information obtained from one or more monitoring devices. In some embodiments, the data analysis software 2648 collects and analyzes data from the monitoring devices in an ICU. The data analysis software 2648 can also present charts, graphs, and statistics to a user of the computer system 2646];
program memory storing computer code [Rule at Para. 0371 teaches in certain embodiments, code modules may be implemented and/or stored in any type of computer-readable medium or other computer storage device (e.g., hard disks, RAM, ROM, flash memory, etc.).];
and a processor for reading and implementing the computer code in the program memory, wherein the program memory stores computer code for implementation by the processor to [Rule at Para. 0195 teaches the algorithm processor 416 (FIG. 4) (or any other suitable processor or processors) may be configured to receive from the analyzer 2010 the wavelength-dependent optical measurements Cs(λi) of the fluid sample. In some embodiments, the optical measurements comprise spectra such as, for example, optical densities ODi measured in each of the N filter passbands centered around wavelengths λi];
control the test data interface to receive the point of care test data for the patient over the communications network from the point of care device [Rule at Para. 0107 teaches the system 400 shown in FIG. 4 includes a display system 414 that provides for communication of information to a user of the system 400. In some embodiments, the display 414 can be replaced by or supplemented with other communication devices that communicate in non-visual ways. The display system 414 can include a display processor that controls or produces an interface to communicate information to the user. The display system 414 can include a display screen. One or more parameters such as, for example, blood glucose concentration, system 400 operating parameters, and/or other operating parameters can be displayed on a monitor (not shown) associated with the system 400. An example of one way such information can be displayed is shown in FIGS. 24 and 25. In some embodiments, the display system 414 can communicate measured physiological parameters and/or operating parameters to a computer system over a communications connection],
process the parsed test data using the demographic data and reference data, wherein the reference data specifies at least one demographically dependent normal range [Rule at Para. 0253 teaches accordingly, embodiments of analysis methods that use a Sample Population that includes both normal spectra and spectra from individuals similar to those of the target population and that calibrate for possible interferents provide a good match between the estimated glucose concentration and the measured glucose concentration. As discussed above, a suitable Sample Population may be assembled from the Population Database in order to include normal spectra plus suitable target spectra from individuals that match a desired target population including, for example, ICU patients, trauma patients, a particular demographic group, a group having a common medical condition (e.g., diabetes), and so forth; Rule at Para. 0257 teaches if the analyte concentration is within bounds of the reference standard, the status graphic 2414 may indicate normal (e.g., “Normal Glucose”), or it may not be displayed at all. The status graphic 2414 may have a background color (e.g., red, yellow, green, blue or some other color) when the analyte concentration exceeds the acceptable bounds of the reference standard],
set a flag in the parsed test data when the processing of the parsed test data determines that the parsed test data lies outside the at least one demographically dependent normal range [Rule at Para. 0361 teaches each trend indicator may display areas of the graph associated with a reference standard in a selected high or low contrast color. For example, areas 4905 in a small range below a minimum and/or above maximum level or reference standard may be displayed in yellow or dark yellow, and areas 4907 outside the acceptable levels of the reference standard and the small range above or below the reference standard may be displayed in red or dark red (color interpreted as flag)],
Rule does not teach an electronic health record provider interface for interfacing with at least one electronic heath record provider's computer over the communications network, the at least one electronic health record provider's computer storing electronic health records for patients, the electronic health record provider interface including an application programming interface (API) specific to each electronic health record provider's computer;
control the electronic health record provider interface to use the point of care test data for a patient to identify an API to be used for interfacing to the respective electronic health record provider's computer and using the identified API to retrieve demographic data for the patient from said electronic health record provider's computer,
parse the received point of care test data by using a device-specific module to standardize the data format according to a stored test-type library,
generate an order identifier when the order identifier is detected as missing, and embed the order identifier in the processed test data,
and control the electronic health record provider interface to identify the API to be used for interfacing to said electronic health record provider's computer, and to upload the parsed, processed, and flagged test data to the electronic health provider's computer.
Rentas teaches an electronic health record provider interface for interfacing with at least one electronic heath record provider's computer over the communications network, the at least one electronic health record provider's computer storing electronic health records for patients [Rentas at Para. 0030 teaches in one embodiment the server system includes an electronic health record interface for sending and receiving data to and from electronic health record providers; wherein the software is adapted to be implemented by the processor to control the electronic health record interface to obtain the electronic health recorder provider requirements; Rentas at Para. 0031 teaches in one embodiment the software is adapted to be implemented by the processor to control the electronic health record interface to transmit the complete patient test data to the electronic health record provider], the electronic health record provider interface including an application programming interface (API) specific to each electronic health record provider's computer [Rentas at Para. 0089 teaches each EHR provider's computer 40 and 50 implements a web server 42 and 52 for interfacing via a network interface to the internet 10 and an application server 41 and 51 for providing the required functionality and interface to the respective EHR databases 43 and 53];
control the electronic health record provider interface to use the point of care test data for a patient to identify an API to be used for interfacing to the respective electronic health record provider's computer and using the identified API to retrieve demographic data for the patient from said electronic health record provider's computer [Rentas at Para. 0068 teaches in one embodiment the server system includes a network interface for transmission of the patient test data to one of a plurality of electronic health record providers' computers, wherein the software is adapted to be implemented by the processor to identify the electronic health record providers' computer to which the patient test data is to be transmitted, to select an interface module for the identified electronic health record providers' computer, to implement the selected interface module to convert the format of the patient test data to a format specific to the electronic health record providers' computer, and to control the network interface to transmit the converted patient test data to the electronic health record providers' computer (interpret to combine with demographic data of Rule)],
parse the received point of care test data by using a device-specific module to standardize the data format according to a stored test-type library [Rentas at Para. 0012 teaches this aspect of the invention enables patient test data for different point of care devices outputting data in different formats to be translated or parsed into and stored in a data format, which is common for common patient test types e.g. urinalysis; Rentas at Para. 0067 teaches a seventh generalised embodiment comprises a server system for processing patient test data from a plurality of point of care device types, the server system comprising a point of care interface for receiving patient test data from a point of care computer, the point of care computer receiving the patient test data from a plurality of point of care device types and passing it unchanged, the plurality of point of care device types having different data formats; a library store storing a library of test type objects, each test type object defining a common data structure for a type of patient test],
[ … ] … and embed the order identifier in the processed test data [Rentas at Para. 0096 teaches the EHR provider can be identified from an order identifier associated with the patient test; Rentas at Para. 0105 teaches the list will include order identifiers which will either inherently include an EHR provider identifier or a separate EHR provider identifier will be provided. The operator then selects an appropriate order that matches the patient test performed (step S52) and this selection is transmitted back to the service provider's computer 60, where the patient test data for the test is stored in the cache 670 with the order identifier and patient identifier (step S53)],
and control the electronic health record provider interface to identify the API to be used for interfacing to said electronic health record provider's computer, and to upload the parsed, processed, and flagged test data to the electronic health provider's computer [Rentas at Para. 0070 teaches in one embodiment the computer implemented method includes identifying an electronic health record providers' computer to which the patient test data is to be transmitted using a network interface; selecting an interface module for the identified electronic health record providers' computer]..
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine test data interface of Rule with the provider interface of Rentas with the motivation to reduce operator input errors [Rentas at Para. 0106].
Rule/Rentas does not teach generate an order identifier when the order identifier is detected as missing, … [ … ]
Rao teaches generate an order identifier when the order identifier is detected as missing [Rao at Para. 0103 teaches the contact 410 is an e-mail, voice response, mail or combinations thereof. Any of the alert 414, document request 412, form 408 or notice related to scheduling 406 may be provided directly to the patient. For example, an alert, email or phone call is performed automatically, in response to mining 402, to schedule a visit, or try to collect information by the phone in order to gather more or missing information (interpret to combine with order identifier of Rentas)], … [ … ]
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas with the detection of Rao with the motivation to improve the treatment of patients
Regarding Claim 2
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule further teach wherein the point of care test data includes test data for one or more analytes [Rentas at Para. 0078 teaches the point of care devices can comprises any device for carrying out any patient medical test at a point of care facility or even at the patients premises, such as blood glucose testing, blood gas and electrolytes analysis], the reference data specifies at least one demographically dependent normal range for a plurality of analytes [Rule at Para. 0253 teaches Population Database in order to include normal spectra plus suitable target spectra from individuals that match a desired target population including, for example, ICU patients, trauma patients, a particular demographic group, a group having a common medical condition (e.g., diabetes), and so forth], and the flag is set for an analyte when the processing of the point of care test data determines that data for the analyte lies outside the normal range for the analyte [Rule at Para. 0361 (see Claim 1 for explanation)].
Regarding Claim 3
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule further teach wherein reference data includes user identifiers, and the at least one demographically dependent normal range for point of care test data is specific to each user identifier [Rule at Para. 0253 (see Claim 2 for explanation)], a user identifier is identified for a user requiring the point of care test data [Rentas at Para. 0163 teaches patient test data will comprise some common fields such as patient identifier, data and time of test, test type, and device identifier and some fields that are test specific e.g. for a urinalysis test the data will include data for glucose level and pH. The additional required data to be input by an operator for a urinalysis test can include colour and clarity of the sample (patient identifier interpreted as user identifier)], and the flag in the point of care test data is set when the processing of the point of care test data determines that the point of care test data lies outside the normal range specific to the identified user identifier [Rule at Para. 0361 (see Claim 1 for explanation)].
Regarding Claim 4
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule further teach wherein reference data includes device identifiers [Rentas at Para. 0024 teaches in one embodiment the application is adapted to be implemented by the processor to add point of care computer identifier data and device identifier data to the test data for transmission by the network interface to the server system], and the at least one demographically dependent normal range for point of care test data is specific to each device [Rule at Para. 0253 (see Claim 2 for explanation)], a device identifier is identified for a device providing the point of care test data [Rentas at Para. 0098 teaches in addition to the POC device name, each POC device is assigned a unique identifier since a POC computer may be connected with more than one POC device with the same name e.g. ABC Inc Blood Tester. These entered configuration parameters are then stored with a device identifier (or the device name) (step S5)], and the flag in the point of care test data is set when the processing of the point of care test data determines that the point of care test data lies outside the normal range specific to the identified device [Rule at Para. 0361 (see Claim 1 for explanation)].
Regarding Claim 5
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule further teach wherein reference data includes electronic health record provider identifiers [Rentas at Para. 0113 teaches the list will include order identifiers which will either inherently include an EHR provider identifier or a separate EHR provider identifier will be provided], and the at least one demographically dependent normal range for point of care test data is specific to each electronic health record provider [Rentas at Para. 0089 teaches electronic health records (EHR) are stored and maintained by EHR providers. There are a number of such providers available and different medical care providers use different EHR providers. The EHR providers host the HER records in databases 43 and 53 on computers 40 and 50. Each EHR provider's computer 40 and 50 implements a web server 42 and 52 for interfacing via a network interface to the internet 10 and an application server 41 and 51 for providing the required functionality and interface to the respective EHR databases 43 and 53.], an electronic health record provider identifier is identified for an electronic health record provider to which the point of care test data is to be uploaded [Rentas at Para. 0106 teaches the patient test data is also passed to the EHR interface 630 where the EHR provider to which the patient test data is to be sent is identified from the order identifier and any additional EHR identifier. This identification is used to implement a specific EHR module 631 for the patient test data to be transmitted to the EHR provider.], and the flag in the point of care test data is set when the processing of the point of care test data determines that the point of care test data lies outside the normal range specific to the electronic health record provider [Rule at Para. 0361 (see Claim 1 for explanation)].
Regarding Claim 6
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule further teach wherein the point of care test data includes at least one label for an analyte, and the point of care test data is further processed to standardise the at least one label according to stored requirements of a standard specification, a user, or an electronic health record provider [Rentas at Para. 0164 teaches continuing with the example of a urinalysis, an instantiation of the test type for a specific device would include a Device ID e.g. the serial number and data comprising: pH, glucose concentration, colour, clarity, ketone, blood, nitrite, protein, lucasite esterase, bilurubine and specific gravity; Rentas at Para. 0175 teaches the QC data and/or maintenance data for the POC device is located in the compliance database 65 and it is compared with compliance requirements for the POC device. If the patient test data is determined to be compliant (step S74), the patient name or patient identifier that was entered by the operator with the manual data input is transmitted via the service provider's computer to the EHR provider's computer where the data is received (step S49 in FIG. 7a). The process then continues as in the embodiment of FIGS. 7a and 7b from step S49].
Claim 7 rejected under 35 U.S.C. 103(a) as being unpatentable over Rule, Rentas, Rao as applied to claim 1 above, and further in view of Bucur et al (US Publication No. 20120203576).
Regarding Claim 7
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule does not teach wherein the processing of the patient test data further includes the addition of the retrieved demographic data for the patient in the patient test data.
Bucur teaches wherein the processing of the patient test data further includes the addition of the retrieved demographic data for the patient in the patient test data [Bucur at Para. 0041 teaches the patient identification algorithm 4 may be based on comparing patient demographic data (N, A, . . . ) stored in a local patient information record 3 and in a remote patient information record 3a].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas, Rule with the processing of Bucur with the motivation to improve linking corresponding patient information records at different entities.
Claim 8 rejected under 35 U.S.C. 103(a) as being unpatentable over Rule, Rentas, Rao as applied to claim 1 above, and further in view of Bucur et al (US Publication No. 20120203576) in view of Aguiar et al (US Publication No. 20150025808).
Regarding Claim 8
Rule/Rentas/Rule teach the server system of claim 1,
Rule/Rentas/Rule do not teach wherein identifiers are stored to identify patient test data for test results that are required to be notified to a relevant authority when patient test data is flagged,
and the stored computer code is adapted for implementation by the processor to automatically use the identifiers to identify when the patient test data is required to be notified to the relevant authority,
and to generate a report to the relevant authority when the flag is set in the patient test data and the patient test data is required to be notified to the relevant authority.
Aguiar teaches when patient test data is flagged [Aguiar at Para. 0043 teaches thus, even in instances in which the test result may be considered “normal” as compared to the standard/reference data, when the test result is outside of a variance from the patient-specific data, an indication can be provided. The indication may be provided in the form of a report, a message, an item on a graphical user interface (GUI) or display, etc. The indication can be interpreted as a warning that the patient has shown a change in the test result that otherwise may have been ignored since the test result was within the normal range of the reference data (interpret to combine with identifiers of Rentas)],
and the stored computer code is adapted for implementation by the processor to automatically use the identifiers to identify when the patient test data is required to be notified to the relevant authority [Aguiar at Para. 0076 teaches the computing device may generate a report, and can be programmed to send or provide the report to the doctor or to the patient, and the sending of the report to the patient can be based on whether the test results are deemed positive or negative],
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas, Rule with the autority of Aguiar with the motivation to improve detection of significant change within a patient.
Rule/Rentas/Rule/Aguiar do not teach and to generate a report to the relevant authority when the flag is set in the patient test data and the patient test data is required to be notified to the relevant authority.
Bucur teaches and to generate a report to the relevant authority when the flag is set in the patient test data and the patient test data is required to be notified to the relevant authority [Bucur at Para. 0029 teaches the entities 1,1a may have respective patient databases. These databases comprise patient information records 3,3a. For example, the patient information records 3 of the database of entity 1 may comprise a patient identifier (ID), patient name (N), patient address (A), and/or other demographic information ( . . . )].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas, Rao, Aguiar with the report of Bucur with the motivation to improve linking corresponding patient information records at different entities.
Claims 9-14, 17-19 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over Rule et al (US Publication No. 20150045641) in view of Rentas et al (US Publication No. 20150051922) in view of Aguiar et al (US Publication No. 20150025808) in view of Rao et al (US Publication No. 20060265253).
Regarding Claim 9
Rule teaches a method at a server system for processing patient test data from at least one point of care device, the method comprising:
receiving point of care test data for a patient from at least one point of care device over a communications network from the point of care device [Rule at Para. 0087, 0284 (see Claim 1 for explanation)];
processing the parsed test data using the demographic data and reference data, wherein the reference data specifies at least one demographically dependent normal range [Rule at Para. 0253, 0257 (see Claim 1 for explanation)];
setting a flag in the parsed test data when the processing of the parsed test data determines that the parsed test data lies outside the at least one demographically dependent normal range [Rule at Para. 0361 (see Claim 1 for explanation)];
Rule does not teach using an electronic health record provider interface interfacing with at least one electronic heath record provider's computer over the communications network to use the point of care test data for a patient to identify an application programming interface (API) to be used for interfacing to the respective electronic health record provider's computer, the at least one electronic health record provider's computer storing electronic health records for patients, the electronic health record provider interface including an API specific to each electronic health record provider's computer ;
parsing the received point of care test data by using a device-specific module to standardize the data format according to a test-type library;
retrieving demographic data for the patient from said electronic health record provider's computer using the identified API;
generating an order identifier when the order identifier is detected as missing, and embedding the order identifier in the processed test data;
and identifying the API to be used for interfacing to said electronic health record provider's computer, and uploading the parsed, processed, and flagged test data to the electronic health provider's computer.
Rentas teaches using an electronic health record provider interface interfacing with at least one electronic heath record provider's computer over the communications network to use the point of care test data for a patient to identify an application programming interface (API) to be used for interfacing to the respective electronic health record provider's computer, the at least one electronic health record provider's computer storing electronic health records for patients, the electronic health record provider interface including an API specific to each electronic health record provider's computer [Rentas at Para. 0030-0031, 0089 (see Claim 1 for explanation)];
parsing the received point of care test data by using a device-specific module to standardize the data format according to a test-type library [Rentas at Para. 0012, 0067 (see Claim 1 for explanation)];
[ … ] … and embedding the order identifier in the processed test data [Rentas at Para. 0096, 0105 (see Claim 1 for explanation)];
and identifying the API to be used for interfacing to said electronic health record provider's computer, and uploading the parsed, processed, and flagged test data to the electronic health provider's computer [Rentas at Para. 0070 (see Claim 1 for explanation)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine test data interface of Rule with the provider interface of Rentas with the motivation to reduce operator input errors [Rentas at Para. 0106].
Rule/Rentas does not teach retrieving demographic data for the patient from said electronic health record provider's computer using the identified API;
generating an order identifier when the order identifier is detected as missing, … [ … ]
Aguiar teaches retrieving demographic data for the patient from said electronic health record provider's computer using the identified API Aguiar at Para. 0005 teaches in one example, a method is provided that comprises obtaining, by a computing device, a result of a diagnostic test performed on a patient. The method also comprises comparing, by the computing device, the result based on patient-specific data, and the patient-specific data includes one or more previous test results of the diagnostic test previously performed on the patient (patient specific data interpreted to include demographic data; interpret to combine with ehr provider’s computer of Rentas)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas with the report of Aguiar with the motivation to improve detection of significant change within a patient.
Rule/Rentas/Aguiar does not teach generating an order identifier when the order identifier is detected as missing, … [ … ]
Rao teaches generating an order identifier when the order identifier is detected as missing [Rao at Para. 0103 (see Claim 1 for explanation)], … [ … ]
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas, Aguiar with the detection of Rao with the motivation to improve the treatment of patients
Regarding Claim 10
Claim(s) 10 is/are analogous to Claim(s) 2, thus Claim(s) 10 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 2.
Regarding Claim 11
Claim(s) 11 is/are analogous to Claim(s) 3, thus Claim(s) 11 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 3.
Regarding Claim 12
Claim(s) 12 is/are analogous to Claim(s) 4, thus Claim(s) 12 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 4.
Regarding Claim 13
Claim(s) 13 is/are analogous to Claim(s) 5, thus Claim(s) 13 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 5.
Regarding Claim 14
Claim(s) 14 is/are analogous to Claim(s) 6, thus Claim(s) 14 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 6.
Regarding Claim 17
Rule teaches a non-transitory storage medium storing computer readable code for controlling a computer to:
receive point of care test data for a patient from at least one point of care device over a communications network [Rule at Para. 0087, 0284 (see Claim 1 for explanation)] ;
process the parsed test data using the demographic data and reference data, wherein the reference data specifies at least one demographically dependent normal range [Rule at Para. 0253, 0257 (see Claim 1 for explanation)];
set a flag in the parsed test data when the processing of the parsed test data determines that the parsed test data lies outside the at least one demographically dependent normal range [Rule at Para. 0253, 0257 (see Claim 1 for explanation)];
Rule does not teach parse the received point of care test data by using a device-specific module to standardize the data format according to a stored test-type library;
use an electronic health record provider interface interfacing with at least one electronic heath record provider's computer over the communications network to use the point of care test data for a patient to identify an application programming interface (API) to be used for interfacing to the respective electronic health record provider's computer, the at least one electronic health record provider's computer storing electronic health records for patients, the electronic health record provider interface including an API specific to each electronic health record provider's computer;
retrieve demographic data for the patient from a said electronic health record provider's computer using the identified API;
generate an order identifier when the order identifier is detected as missing, and embed the order identifier in the processed test data;
and identify the API to be used for interfacing to said electronic health record provider's computer and upload the parsed, processed, and flagged test data to the electronic health provider's computer.
Rentas teaches parse the received point of care test data by using a device-specific module to standardize the data format according to a stored test-type library [Rentas at Para. 0012, 0067 (see Claim 1 for explanation)];
use an electronic health record provider interface interfacing with at least one electronic heath record provider's computer over the communications network to use the point of care test data for a patient to identify an application programming interface (API) to be used for interfacing to the respective electronic health record provider's computer, the at least one electronic health record provider's computer storing electronic health records for patients, the electronic health record provider interface including an API specific to each electronic health record provider's computer [Rentas at Para. 0030-0031, 0089 (see Claim 1 for explanation)];
[ … ] … and embed the order identifier in the processed test data [Rentas at Para. 0096, 0105 (see Claim 1 for explanation)];
and identify the API to be used for interfacing to said electronic health record provider's computer and upload the parsed, processed, and flagged test data to the electronic health provider's computer [Rentas at Para. 0070 (see Claim 1 for explanation)].
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine test data interface of Rule with the provider interface of Rentas with the motivation to reduce operator input errors [Rentas at Para. 0106].
Rule/Rentas does not teach retrieve demographic data for the patient from a said electronic health record provider's computer using the identified API;
generate an order identifier when the order identifier is detected as missing, … [ … ]
Aguiar teaches retrieve demographic data for the patient from a said electronic health record provider's computer using the identified API [Aguiar at Para. 0005 (see Claim 9 for explanation)];
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas with the report of Aguiar with the motivation to improve detection of significant change within a patient.
Rule/Rentas/Aguiar do not teach generate an order identifier when the order identifier is detected as missing, … [ … ]
Rao teaches generate an order identifier when the order identifier is detected as missing [Rao at Para. 0103 (see Claim 1 for explanation)], … [ … ]
It would have been prima facie obvious skill in the art, at the time of effective filing, to combine the references of Rule, Rentas, Aguiar with the detection of Rao with the motivation to improve the treatment of patients
Regarding Claim 18
Claim(s) 18 is/are analogous to Claim(s) 2, thus Claim(s) 18 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 2.
Regarding Claim 19
Claim(s) 19 is/are analogous to Claim(s) 3, thus Claim(s) 19 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 3.
Claims 15-16, 20 rejected under 35 U.S.C. 103(a) as being unpatentable over Rule, Rentas, Aguiar, Rao as applied to claim 9, 17 above, and further in view of Bucur et al (US Publication No. 20120203576).
Regarding Claim 15
Claim(s) 15 is/are analogous to Claim(s) 7, thus Claim(s) 15 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 7.
Regarding Claim 16
Claim(s) 16 is/are analogous to Claim(s) 8, thus Claim(s) 16 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 8.
Regarding Claim 20
Claim(s) 20 is/are analogous to Claim(s) 8, thus Claim(s) 20 is/are similarly analyzed and rejected in a manner consistent with the rejection of Claim(s) 8.
Response to Arguments
Rejection under 35 U.S.C. § 101
Regarding the rejection of Claims 1-20, the Examiner has considered the Applicant’s arguments in light of the present amendments and withdraws the rejection. The claimed invention provides a practical application in the form of a technical solution to a technical problem. As described in the Background of the specification POCT devices cause the problem of a lack of standardization with existing EMR systems and the present claims solve that problem.
Rejection under 35 U.S.C. § 102/103
Regarding the rejection of Claims 1-20, the Examiner has considered the Applicant’s arguments; however, these arguments are moot given the new grounds of rejection as afforded by the present RCE.
Conclusion
The prior art made of record and not relied upon in the present basis of rejection are noted in the attached PTO 892 and include:
ALBRO et al (Foreign Publication WO-2010002376-A1) discloses a system and method for contextualizing input and presentation of patient information in Electronic Health Record systems.
Rinaldo et al (US Publication No. 20150294075) discloses a method for identifying a status of a particular patient with respect to one or more medical conditions.
St Clair et al (US Publication No. 20070055552) discloses a method for creating an electronic health record and analyzing that record to present a summary report.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN C EDOUARD whose telephone number is (571)270-0107. The examiner can normally be reached M-F 730 - 430.
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, Robert Morgan can be reached on (571) 272 - 6773. 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.
/JONATHAN C EDOUARD/Examiner, Art Unit 3683
/JASON S TIEDEMAN/Primary Examiner, Art Unit 3683