DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the amendment filed on 05/05/26.
Claims 1, 11 and 20 have been amended and are hereby entered.
Claims 2-10, 12-19 have been canceled.
Claims 21-37 have been added.
Claims 1, 11 and 20-37 are currently pending and have been examined.
This action is made final.
Continuity/Priority Date
Status of this application as a continuation of Application No. 15/867,810, filed
01/11/2018, which claims priority to Provisional Application No. 62/501,275, filed 05/04/2017, is
acknowledged. Accordingly, a priority date of 05/04/2017 has been given to the instant
application.
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, 11, 20-37 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.
The newly added recitations within Claims 1, 11, 21 copied below appear to constitute new matter. In particular, Applicant does not point to, nor was Examiner able to find support for this newly added language within the specification as originally filed. As such, Applicant is respectfully requested to clarify the above issues and to specifically point out support for the newly added limitations in the originally filed spec and claims.
storing, in the memory of the first electronic device, previously retrieved metadata attributes for a clinical data object returned by the clinical data entry system in response to prior API requests;
sending, via the network interface, to the clinical data entry system over a network, a first API request formatted in accordance with the healthcare data interchange standard, wherein the first API request is structured to retrieve only metadata attributes corresponding to one or more clinical data objects without retrieving full clinical data content of the one or more clinical data objects;
receiving, via the network interface, from the clinical data entry system over the network, in response to the first API request, retrieved metadata attributes corresponding to the one or more clinical data objects;
comparing the retrieved metadata attributes corresponding to the one or more clinical data objects with the previously retrieved metadata attributes stored in the memory;
determining, based on the comparing, that at least one clinical data object of the one or more clinical data objects is associated with the one or more changes in the PHR repository; and
in response to determining that the at least one clinical data object is associated with the one or more changes, sending, via the network interface, to the clinical data entry system over the network, a second API request formatted in accordance with the healthcare data interchange standard, wherein the second API request requests clinical data content of the at least one clinical data object associated with the one or more changes;
for each determined change of the one or more changes in the PHR repository, identifying retrieved clinical data and metadata attributes associated with the determined change.
Examiner acknowledges Applicant’s remarks at pages 17-19 of remarks dated 05/05/26.
Regarding citations:
Paragraph [0020] discloses:
These key algorithms may read the Unique Resource Identifier (URI) component associated with the resource being monitored by EMR message monitor application 114 and perform a ternary check on the resources being updated, checking the instance's meta attribute. If this meta attribute has changed and there is an EPOCH change, for instance, the domain resource's “valueQuanity” attribute and coding value may be determined. In some embodiments, the valueQuantity is attributed by the “Observation” resource. The observation's “patient's recorded temperature information” may be defined as URI values assigned to observational LOINC® codes (see https://loinc.org). A patient's temperature may be in the Observational subcategory vital-signs, which may be nomenclated as universal unique identifiers. A patient's body temperature has a coding value of 8310-5 and the patient's oral temperature has a coding value of 8333-1 under the LOINC standard.
Para. [0021] discloses:
MR message monitor application 114 accepts an MXN spreadsheet (cardinality of 5 . . . , 1 . . . respectively) and iterates through each row in this embodiment. The header for each cell in a row corresponds to the conditions “Resource,” “Type,” “Operation,” “Value,” or “Resolution.” If resource, type, operation, and value match the instance's characteristics and the condition is evaluated as true, some embodiments immediately trigger and perform an appropriate API call, incumbent on the Resolution defined for this condition case expressed herein.
Examiner submits that the specification and cited paragraphs do not provide adequate support for Claims 1, 11 and 20 as amended. Applicant repeatedly argues the “two-stage, metadata-gated” structure with respect to 101 arguments, however, Examiner is unable to find support for this concept of such two-stage metadata-gated structure in the original disclosure. For example, Applicant has not cited to, nor can Examiner find support for limitations pertaining to: storing previously retrieved metadata attributes for a clinical object returned by the clinical data entry system in response to prior API requests, sending…a first API request…structured to retrieve only metadata attributes corresponding to one or more clinical data objects without retrieving full clinical data content of the one or more clinical data objects; retrieving…in response to the first API request, retrieved metadata attributes corresponding to the one or more clinical data objects; comparing the retrieved metadata attributes with the previously retrieved metadata attributes stored in the memory; determining, based on the comparing, that at least one clinical data object of the one or more clinical data objects is associated with the one or more changes in the PHR repository; in response to determining that the at least one clinical data object is associated with the one or more changes, sending…a second API request…wherein the second API request requests clinical data content of the at least one clinical data objected associated with the one or more changes; for each determined change of the one or more changes in the PHR repository, identifying retrieved clinical data and metadata attributes associated with the determined change.
The cited paragraphs do not appear to provide sufficient support for the granularity of the instant claims as currently presented. Examiner specifically notes that there does not appear to be support for the concept of using two different API requests; a first API request to request metadata attributes and subsequently issuing a second API request when the retrieved metadata attributes indicate a change in the PHR repository to request clinical data content.
Regarding citations to para. [0032], para. [0032] discloses:
In some embodiments, EMR message monitor application 114 periodically scans EMR application 112 (e.g., every few minutes) searching for changes in a time stamp (e.g., an EPOCH time stamp), the patient treatment team and/or regimen (e.g., additional staff to the treatment team, staff removed from the treatment team, treatment updates or changes, etc.), changes in patient location, etc. More specifically, in some embodiments, EMR message monitor application 114 makes calls to EMR application 112 using a “fetch all” process for the desired resources that have changed by cURLing the results by a rest API call.
Examiner notes that para. [0032], as stated above, pertains to “some embodiments”; there is no disclosure of continuity from what is disclosed in paras. [0020]-[0021] to para. [0032] with regard to “first” and “second” API requests based on a two-step metadata-gated process. Para. [0032] merely discloses that the message monitor scans EMR application to search for a change, and in some embodiments it may make calls to EMR application using a “fetch all” process for resources that have changed. There does not appear to be disclosure in [0032] of first obtaining metadata prior to making the rest API call to retrieve the desired resources that have changed.
Dependent claims 21-37 inherit the deficiencies of their respective parent claims.
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, 11, 20-37 are rejected under 35 U.S.C.101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1
Claims 1, 21-31 are drawn to a method, Claims 11, 32-37 are drawn to a device, and Claim 20 is drawn to a computer-implemented system, each of which are within the four statutory categories. Claims 1, 11, 20-37 are further directed to an abstract idea on the grounds set out in detail below.
Step 2A Prong 1
Claim 1 recites implementing the steps of:
retrieving and monitoring, for one or more changes in a personal health record (PHR) repository having a plurality of patient records associated with a plurality of patients;
sending a first request to retrieve only metadata attributes corresponding to one or more clinical data objects without retrieving full clinical data content of the one or more clinical data objects, wherein each clinical data object is a structured data object and includes clinical data and metadata attributes associated with at least one patient record of the plurality of patient records, wherein the metadata attributes of each clinical data object include at least: an object identifier assigned to and uniquely identifying the clinical data object within the PHR repository; and a timestamp attribute reflecting a last-modified time associated with the clinical data object
receiving in response to the first request, retrieved metadata attributes corresponding to the one or more clinical data objects
comparing the retrieved metadata attributes corresponding to the one or more clinical data objects with previously retrieved metadata attributes;
determining, based on the comparing, that at least one clinical data object of the one or more clinical data objects is associated with the one or more changes in the PHR repository; and
in response to determining that the at least one clinical data object is associated with the one or more changes, sending a second request to request clinical data content of the at least one clinical data object associated with the one or more changes;
for each determined change of the one or more changes in the PHR repository, identifying retrieved clinical data and metadata attributes associated with the determined change;
selecting, from a set of rules, a first rule corresponding to the retrieved clinical data and metadata attributes associated with the determined change, wherein the first rule is represented by a rule definition, the rule definition including one or more fields defining one or more parameters of a comparison operation for evaluating the determined change and a resolution field defining an action to be executed when the comparison operation satisfies a triggering condition;
determining, by applying the rule to the retrieved clinical data and metadata attributes associated with the determined change, that the triggering condition is satisfied and that an alert notification corresponding to the determined change is to be transmitted;
in response to detecting the triggering condition by applying the first rule to the retrieved clinical data and metadata attributes associated with the determined change:
generating an alert notification having information associated with the determined change in the PHR repository;
providing an indication that includes the alert notification to be delivered
These steps amount to managing personal behavior or relationships or interactions
between people and therefore are directed to certain methods of organizing human activity. Monitoring patient records to detect a change by retrieving and comparing metadata attributes to previously received metadata attributes, determining that at least one clinical data object is associated with a PHR change, responsively requesting clinical data content associated with the change, selecting a rule pertaining to the retrieved clinical data and determined change pertaining to evaluation of the change and resolution to be initiated when a trigger condition is satisfied, determining that a triggering condition has been satisfied and generating an alert notification with the information associated with the determined change and providing the alert notification are personal behaviors that may be performed by healthcare providers when issuing a notification to a patient’s family member of a change in patient condition.
Independent claims 11, 20 recite substantially similar limitations and also recite an abstract idea under the same analysis.
The above claims are therefore directed to an abstract idea.
Step 2A Prong 2
This judicial exception is not integrated into a practical application because the additional
elements within the claims only amount to:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
The independent claims additionally recite:
a first electronic device having processing circuitry operably coupled to memory and a network interface (Claim 1), as implementing the steps of the abstract idea
a first electronic device associated with a distributed electronic healthcare data environment, comprising: a processing circuitry; a memory; a network interface; wherein the memory is operationally coupled to the processing circuitry, the memory containing instructions executable by the processing circuity whereby the processing circuitry is configured to as implementing the steps of the abstract idea (Claim 11)
an application programming interface (API) mediated access architecture as implementing the steps transmission/receipt of data and data requests
a healthcare data interchange standard as the means of formatting clinical data objects
a clinical data entry system as the entity from which retrieved metadata attributes corresponding to one or more clinical data objects are received
a medical facility computing infrastructure including: at least one workstation device having a processor, memory, and network interface; at least one server system comprising a processor, memory, and network interface; and a software application platform comprising a plurality of integrated modules executable across the workstation device and server system, the software application platform including an EMR monitoring module executable on the workstation device and a server-side automated alert module executable on the server system, with the EMR monitoring module configured to as implementing the steps of the abstract idea (Claim 20 only).
a network interface as the means of sending/receiving information
a first programmable logic rule as an electronic means of applying a set of rules to retrieved clinical data and meta attributes data to generate an alert
alert “payload” as providing information associated with a change in PHR repository
a second electronic device / server system as the entity which receives an indication that includes the alert payload; and as implementing the step of transmit the alert notification to a mobile computing device associated with the authorized recipient based on stored patient authorization data
wherein the identifying, selecting, generating, and transmitting steps are performed by the processing circuitry of the first electronic device, such that
the clinical data entry system is not required to perform processing operations
beyond generating responses to the API requests issued by the first electronic
device
The broad recitation of general purpose computing elements at a high level of generality only amounts to mere instructions to implement the abstract idea using computing components as tools:
Regarding the “electronic devices”, e.g., a first electronic device having processing circuitry operably coupled to memory and a network interface (Claim 1); a first electronic device associated with a distributed electronic healthcare data environment, comprising: a processing circuitry; a memory; a network interface; wherein the memory is operationally coupled to the processing circuitry, the memory containing instructions executable by the processing circuity whereby the processing circuitry is configured to (Claim 11); and a second electronic device (Claims 1, 11, 20) the electronic devices are understood to be general purpose computing devices functioning in their ordinary capacities; see at least para. [0051], “[0051] FIG. 4 is a block diagram illustrating a computing system 400 configured to provide an automated alert system, according to an embodiment of the present invention. For instance, computing system may be a server, a laptop computer, a desktop computer, a tablet, a smart phone, or any other suitable computing system without deviating from the scope of the invention. Computing system 400 includes a bus 405 or other communication mechanism for communicating information, and processor(s) 410 coupled to bus 405 for processing information. Processor(s) 410 may be any type of general or specific purpose processor, including a central processing unit (CPU), an application specific integrated circuit (ASIC), a microcontroller, or any other suitable processing hardware without deviating from the scope of the invention. Processor(s) 410 may also have multiple processing cores, and at least some of the cores may be configured to perform specific functions. Multi-parallel processing may be used in some embodiments. Computing system 400 further includes memory 415 for storing information and instructions to be executed by processor(s) 410.Memory 415 can be comprised of any combination of random access memory (RAM), read only memory (ROM), flash memory, cache, static storage such as a magnetic or optical disk, or any other types of non-transitory computer-readable media or combinations thereof. Additionally, computing system 400 includes a communication device 420, such as a transceiver and antenna, to wirelessly provide access to a communications network”; paras. [0042], “Nurse workstation 110 is presumably the machine location where the practitioner is authorized to make updates or signal event changes in relationship to a patient. In most hospitals, nurse workstation 110 is a desktop that runs EMR application 112 as well. In some embodiments, EMR message monitor application 114 is web-based (e.g., runs on a browser such as Microsoft Internet ExplorerTM10, FirefoxTM Google ChromeTM, or SafariTM); per [0051] as cited above, the computing devices and components (memory, processor, etc.) are understood to be general purpose computing elements functioning in their ordinary capacities.
Regarding a network interface, per para. [0051] this is understood to be a communications device such as a transceiver and antenna to wirelessly provide access to a communications network. As computing system 400 is understood to be a general purpose computing device as discussed above with respect to para. [0051], this element also is given its broadest reasonable interpretation as a general purpose computing element used to apply the abstract idea.
Regarding the medical facility computing infrastructure, per paras. [0018] and [0051], this is interpreted as a collection of general purpose computing elements functioning in their ordinary capacities, e.g., [0018] disclose user device could be “a laptop, a desktop computer, a tablet, a smart watch, or any other suitable user device without deviating from the scope of the invention”; [0051], “FIG. 4 is a block diagram illustrating a computing system 400 configured to provide an automated alert system, according to an embodiment of the present invention. For instance, computing system may be a server, a laptop computer, a desktop computer, a tablet, a smart phone, or any other suitable computing system without deviating from the scope of the invention. Computing system 400 includes a bus 405 or other communication mechanism for communicating information, and processor(s) 410 coupled to bus 405 for processing information. Processor(s) 410 may be any type of general or specific purpose processor, including a central processing unit (CPU), an application specific integrated circuit (ASIC), a microcontroller, or any other suitable processing hardware without deviating from the scope of the invention… Computing system 400 further includes memory 415 for storing information and instructions to be executed by processor(s) 410. Memory 415 can be comprised of any combination of random access memory (RAM), read only memory (ROM), flash memory, cache, static storage such as a magnetic or optical disk, or any other types of non-transitory computer-readable media or combinations thereof. Additionally, computing system 400 includes a communication device 420, such as a transceiver and antenna, to wirelessly provide access to a communications network”.
Regarding the at least one workstation device having a processor, memory, and network interface (Claim 20), para. [0042] discloses “Nurse workstation 110 is presumably the machine location where the practitioner is authorized to make updates or signal event changes in relationship to a patient. In most hospitals, nurse workstation 110 is a desktop that runs EMR application 112 as well. In some embodiments, EMR message monitor application 114 is web-based (e.g., runs on a browser such as Microsoft Internet ExplorerTM10, FirefoxTM Google Chrome TM, or Safari TM; per para. [0051] as cited above, the recited computing elements are all understood to be general purpose computing elements functioning in their ordinary capacities.
Regarding the at least one server system comprising a processor, memory, and network interface (Claim 20), per para. [0051] as cited above, these are all understood to be general purpose computing elements functioning in their ordinary capacities; and
Regarding a software application platform comprising a plurality of integrated modules executable across the workstation device and server system (Claim 20), the specification discloses, at [0035], “Application server 120 runs on the cloud 130 in this embodiment. In some embodiments, cloud 130 may be the IBM® Cloud. Application server 120 provides a set of cloud computing services that include infrastructure as a service (laaS), software as a service (SaaS), and platform as a service (PaaS) offered through public, private, and/or hybrid cloud delivery models, in addition to the components that make up those clouds capabilities; [0056], It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like; [0057] A module may also be at least partially implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. See above citations and discussions regarding the workstation advice and server system. No particulars of the platform and modules are provided. This limitation amounts to mere instructions to apply the abstract idea on a general purpose computer using software.
Regarding the healthcare data interchange standard, no particulars of this element are given. Per para. [0035] this is understood to be using a known healthcare data interchange such as FHIR in its normal capacity for formatting data.
Regarding an EMR monitoring module executable on the workstation device and a server-side automated alert module executable on the server system (Claim 20): Regarding the EMR monitoring module, this element is only described at a high level of detail, e.g., para. [0006] teaches it may interface with hospital EMR; para. [0042] discloses “In some embodiments, EMR message monitor application 114 is web-based (e.g., runs on a browser such as Microsoft Internet ExplorerTM, FirefoxTM Google ChromeTM, or SafariTM). In some embodiments, it should be noted that nurse workstation 110 can perform all of the functionality associated with application server 120. The user may be able to download client-side code ad run the application natively on nurse workstation 110”), or in terms of the functions it performs (e.g., [0048], [0049]). No specific details of the module are provided, and therefore it is given its broadest reasonable interpretation as a general purpose computing element; Regarding a server-side automated alert module executable on the server system, para. [0036] discloses that “Server-side automated alert application 122 running on application server 20 receives data from EMR message monitor application…parses this data, and temporarily stores it in cache storage 124”. No specific details of the modules are provided, and therefore it is given its broadest reasonable interpretation as a general purpose computing element.
Regarding a first programmable logic rule of a first set of programmable logic rules stored in the memory (Claims 1, 11, 20), paras. [0056] and [0057] disclose ([0056]) “It should be noted that some of the system features described in this specification have been presented as modules, in order to more particularly emphasize their implementation independence…A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like” and ([0057] “A module may also be at least partially implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function”. Therefore, this element is given its broadest reasonable interpretation as software/hardware used to implement the steps of the abstract idea.
Regarding alert “payload” (Claims 1, 11, 20), the specification/claims do not define this term. Therefore, “payload” is given its broadest reasonable interpretation in view of the specification and context of the claims, and is interpreted as electronic data pertaining to an alert, e.g. an electronic alert, and as such, only amounts to mere instructions to apply the abstract idea using a computer.
Regarding “ wherein the identifying, selecting, generating, and transmitting steps are performed by the processing circuitry of the first electronic device, such that the clinical data entry system is not required to perform processing operations beyond generating responses to the API requests issued by the first electronic device” (Claims 1, 11, 20), this is interpreted as indicating that the electronic device implements the steps of the abstract idea. As discussed with respect to various components in this section, the computing devices including the electronic device are all understood to be general purpose computing devices functioning in their ordinary capacities to carry out the steps of the abstract idea (e.g., para. [0051], “server, a laptop computer, a desktop computer, a tablet, a smart phone, or any other suitable computing system without deviating from the scope of the invention”. Merely automating a process using a computer does not automatically confer subject matter eligibility. See MPEP 2106.05(a)(I), example (iii) under “Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality”.
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
The independent claims additionally recite:
a clinical data entry system is configured to read from and write to the PHR repository;
the first electronic device is configured to access information associated with the PHR repository exclusively by issuing API requests to the clinical data entry system, without the first electronic device having direct read or write database access permissions to the PHR repository;
information associated with the plurality of patient records is accessible to the first electronic device only as clinical data objects formatted and returned by the clinical data entry system in response to the API requests
storing, in the memory of the first electronic device, previously retrieved metadata attributes for a clinical data object returned by the clinical data entry system in response to prior API requests
storing a rule definition in a rule table data structure maintained in the memory of the first electronic device
As explained above, the independent claims are directed to an abstract idea in the form of monitoring a patient’s medical data for a change and providing an alert regarding the change. As stated in MPEP 2106.05(g), "[t]he term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim." In the present claim, the above functions, which amount to transmitting, receiving/accessing, or storing of various data, are only nominally or tangentially related to the process of monitoring a patient’s medical data for a change and providing an alert regarding the change, and accordingly constitute insignificant extra-solution activity.
These elements are therefore not sufficient to integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
The above claims, as a whole, are therefore directed to an abstract idea.
Step 2B
The present claims do not include additional elements that are sufficient to amount to
more than the abstract idea because the additional elements or combination of elements amount to no more than a recitation of:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
As explained above, claims 1, 11, and 20 only recite the aforementioned computing elements as tools for performing the steps of the abstract idea, and mere instructions to perform the abstract idea using a computer is not sufficient to amount to significantly more than the abstract idea. MPEP 2106.05(f).
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Likewise, as explained above, the steps identified in Step 2A Prong 2 under “B”, only amounts to insignificant extra-solution activity of the abstract idea.
C. Well-Understood, Routine and Conventional Activities. MPEP 2106.05(d)
In addition to amounting to insignificant extra-solution activity the elements in Section B above constitute well-understood, routine and conventional activity.
The elements of “a clinical data entry system is configured to read from and write to the PHR repository”, “storing, in the memory of the first electronic device, previously retrieved metadata attributes for a clinical data object returned by the clinical data entry system in response to prior API requests” and “storing a rule definition in a rule table data structure maintained in the memory of the first electronic device” only amount to storing and retrieving information in memory, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
The elements of “the first electronic device is configured to access information associated with the PHR repository exclusively by issuing API requests to the clinical data entry system, without the first electronic device having direct read or write database access permissions to the PHR repository” only amounts to transmitting data over a network, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
The element of “information associated with the plurality of patient records is accessible to the first electronic device only as clinical data objects formatted and returned by the clinical data entry system in response to the API requests…” only amounts to transmitting data over a network, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II). (Regarding the subsequent “wherein” clauses, these only narrow the scope of the data transmitted).
Thus, taken alone, the additional elements do not amount to significantly more than the
above-identified judicial exception. Looking at the limitations as an ordered combination adds
nothing that is not already present when looking at the elements taken individually. Their
collective functions merely provide conventional computer implementation.
Depending Claims
Dependent claims are similarly rejected because they either further narrow or define the abstract idea embodied in the claims and/or do not further limit the claim to a practical application or provide an inventive concept such that the claims are subject matter eligible even when considered individually or as an ordered combination.
Claim 21 merely describes wherein the first API request is issued, via the network interface, to the clinical data entry system at controlled intervals ranging from 100 milliseconds to 300,000 milliseconds, which only further narrows the scope of its respective parent claim.
Claim 22 merely describes wherein the first API request is issued, via the network interface, to the clinical data entry system in response to an indication, received by the first electronic device from the clinical data entry system, that one or more clinical data objects have been updated.
Claim 23 merely describes wherein the first API request is further structured to retrieve only clinical data objects associated with at least one of a treatment team, a treatment regimen, a patient location, and a recorded observation associated with a medical condition, which only further narrows the scope of the respective parent claim.
Claim 24 merely describes wherein the rule table data structure includes at least four fields defining the parameters of the comparison operation for evaluating the determined change, the at least four fields comprising: a resource field identifying a clinical data object or a type of clinical data object to which the first programmable logic rule applies; a type field identifying a data type associated with a value in the retrieved clinical data; an operation field identifying a type of comparison to be applied to the value; and a value field defining a reference value for the comparison operation, which only further narrows the scope of the respective parent claim.
Claim 25 merely describes wherein the rule table data structure comprises a plurality of condition rows each defining a discrete rule, which only further narrows the scope of the respective parent claim. Claim 25 merely describes wherein the first electronic device iterates through each condition row to evaluate whether the resource, type, operation, and value fields of the corresponding condition row collectively match characteristics of the retrieved clinical data and metadata attributes associated with the respective change in the PHR repository, and upon determining that the resource, type, operation, and value fields collectively match, the first programmable logic rule evaluates as true and the notification action defined by the resolution field is executed, which only amounts to mere instructions to apply the abstract idea on a computer, e.g., using the electronic device to perform an evaluation and make a determination which leads to executing a notification.
Claim 26 and Claim 36 merely describes wherein the healthcare data interchange standard is Fast Healthcare Interoperability Resource (FHIR) or a successor standard to FHIR, which only further narrows the scope of its respective parent claim.
Claim 27 merely describes wherein the rule table data structure further includes at least one rule of the one or more rules in which the resource field corresponds to a Logical Observation Identifiers Names and Codes (LOINC) identifier, a type field identifies a data type of a recorded measurement value obtained from an observation corresponding to the LOINC identifier, the operation field defines a comparison to be applied to the recorded measurement value, and the value field specifies a target measurement value for comparison against the recorded measurement value, which only further narrows the scope of the respective parent Claim. Claim 27 further recites limitations pertaining to the selecting step further comprises: determining that a component of the retrieved clinical data and metadata attributes associated with the respective change in the PHR repository identifies the observation corresponding to the LOI NC identifier which only amounts to mere instructions to apply the abstract idea on a computer. MPEP 2106.05(f).
Claim 28 merely recites limitations pertaining to further comprising: determining that a component of the retrieved clinical data corresponds to a retrieved measurement value; and applying the operation field of the at least one rule to compare the retrieved measurement value against the target measurement value to evaluate whether the triggering condition defined by the resolution field of the at least one rule is satisfied, which only amount to mere instructions to apply the abstract idea on a computer.
Claim 29 merely describes wherein the transmitting step further comprises: retrieving, from a contact record accessible by the first electronic device, stored contact information associated with a pre-registered authorized individual designated to receive alert notifications; and transmitting the indication to a recipient device associated with the pre-registered authorized individual in accordance with the retrieved stored contact information, which only further narrows the scope of its respective parent claim.
Claim 30 and Claim 37 merely describes wherein the resolution field further defines an urgency level associated with the triggering condition and wherein the generated alert payload includes the urgency level, which only further narrows the scope of its respective parent claim.
Claim 31 and Claim 35 merely describes wherein the transmitting step (operation) comprises transmitting the indication to an intermediary device, which only further narrows the scope of its respective parent claim. Claims 31 and 35 also recite limitations pertaining to the intermediary device being configured to, based on the alert payload, transmit the alert notification to a plurality of user devices distinct from the intermediary device, each of the plurality of user devices being associated with a respective authorized individual from a stored contact list of authorized individuals designated to receive alert notifications, which only amounts to mere instructions to apply the abstract idea.
Claim 32 merely describes wherein the first API request is issued, via the network interface, to the clinical data entry system at controlled intervals that are configurable such that first API requests are issued at intervals between 100 milliseconds and 300,000 milliseconds; and wherein the first API request is further structured to retrieve only clinical data objects associated with at least one of a treatment team, a treatment regimen, a patient location, and a recorded observation associated with a medical condition, which only further narrows the scope of its respective parent claim.
Claim 33 merely describes wherein the rule table data structure includes at least three fields defining the parameters of the comparison operation for evaluating the determined change, the at least three fields comprising: a resource field identifying a clinical data object or a type of clinical data object to which the first programmable logic rule applies; an operation field identifying a type of comparison to be applied to a value in the retrieved clinical data; and a value field defining a reference value for the comparison operation, which only further narrows the scope of its respective parent claim.
Claim 34 merely describes wherein the transmitting operation is further configured to transmit the indication to a recipient device associated with a pre-registered authorized individual designated to receive alert notifications, and wherein the processing circuitry of the first electronic device is further configured, in the transmitting operation, to: retrieve, from a contact record accessible by the first electronic device, stored contact information associated with the pre-registered authorized individual; and transmit the indication to the recipient device in accordance with the retrieved stored contact information, which only further narrows the scope of its respective parent claim.
Dependent claims 21-37 recite additional subject matter which, as discussed above with respect to integration of the abstract idea into a practical application in Claims 1, 11, 20, amount to invoking computers as a tool to perform the abstract idea. Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (electronic devices, processing circuitry, alert “payload”, API, programmable logic, etc.). Looking at the additional elements as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation.
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claims, when analyzed individually, and in combination, are also held to be patent ineligible under 35 U.S.C. 101 as they include all of the limitations of claim 1 or claim 11 respectively. The additional recited limitations of the dependent claims fail to establish that the claims do not recite an abstract idea because the additional recited limitations of the dependent claims merely further narrow the abstract idea. Beyond the limitations which recite the abstract idea, the claims recite additional elements consistent with those identified above with respect to the independent claims which encompass adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claims 21-37, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea without significantly more. These claims fail to remedy the deficiencies of their parent claims above, and are therefore rejected for at least the same rationale as applied to their parent claims above, and incorporated herein.
For the reasons stated, Claims 1, 11, 20-37 fail the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Response to Applicant’s Remarks/Arguments
Please note: When referencing page numbers of Applicant’s response, references are to page numbers as printed.
35 USC 101 Rejections
Applicant’s remarks have been fully considered but are not persuasive. Applicant argues:
Applicant respectfully submits that amended claim 1 is patent eligible under § 101. Amended claim 1 is not directed to a generalized workflow of notifying individuals about patient updates, but rather to a specific technical monitoring architecture implemented in a distributed electronic healthcare environment.
Regarding (A), the Examiner respectfully disagrees. Examiner submits that recitation of computing components (e.g., API requests, electronic devices) only amounts to mere instructions to apply the abstract idea. MPEP 2106.05(f). For example, with respect to the features described at bottom of page 19/top of page 20, the step of comparing retrieved metadata against previously retrieved metadata to determine whether a change has occurred falls within the scope of the abstract idea, e.g., a human operator can compare metadata. Similarly, an affirmative decision that at least one clinical data object is associated with a change is used as a trigger for requesting the clinical data of the changed object, is also within the scope of the abstract idea, e.g., a human operator can determine that a clinical object has changed and request the corresponding clinical data. Any purported improvements may be improvements to the abstract idea – e.g., evaluating a first set of data to determine if additional data is warranted prior to requesting full data. This argument is not persuasive.
These limitations define a concrete technological manner of monitoring and change determination, not a mere result-oriented instruction to communicate information (with respect to remarks at second para. page 20).
Regarding (B), the Examiner respectfully disagrees. Examiner initially submits that the features described herein are directed to the abstract idea – monitoring and change determination, as stated by Applicant at page 20. Monitoring and change determination fall within the scope of the abstract idea, e.g., a human operator can monitor data for changes and determine when a change in data has occurred. As discussed with respect to (A) above, the various computing components (e.g., in this case, programmable logic rule represented by a rule definition stored in a rule table in memory of an electronic device) only amounts to mere instructions to apply the abstract idea. The computing components are understood to be general purpose computing components functioning in their ordinary capacities. For example, the broadest reasonable interpretation of the features to which Applicant cites in this paragraph are understood to be a human operator using a rule which defines one or more parameters for comparing and evaluating a determined change, in which each change parameter has a respective action to be executed when a triggering condition is reached. The above remarks with respect to (A) pertaining to using metadata to determine if additional data is needed are equally applicable to this argument. This argument is not persuasive.
To the extent the Office continues to view the claim as implicating an abstract idea at
Step 2A, Prong One, Applicant respectfully submits that the claim is not "directed to" any such
exception because the claim, considered as a whole, is focused on a particular technical
manner of operation. The claimed method does not merely recite observing patient data and
sending an alert. Rather, as described above, it recites the specific two-stage, metadata-gated
monitoring pipeline implemented in a distributed electronic healthcare data environment, in
which a first-stage retrieval and comparison of only metadata attributes gates any second-stage
retrieval of clinical data content, with all access to the PHR repository conducted exclusively
through standardized API requests and responses.
Regarding (C), the Examiner respectfully disagrees. MPEP 2106. 04(a)(2)(II) states that a claimed invention is directed to certain methods of organizing human activity if the identified claim elements contain limitations that encompass fundamental economic principles or practices, commercial or legal interactions, or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). The Examiner submits that the identified claim elements represent a series of personal behaviors that a person or persons, with or without the aid of a computer, would follow to monitor patient data to determine that a change in condition has occurred and provide a notification to a family member regarding the change in the patient’s condition. The Examiner notes that Applicant’s Background describes communication between healthcare providers and family members pertaining to medical reconciliation, history, change in location and health status as a human task (see para. [0003]; see [0016], designating a person from the treatment team to attempt to reach family members during a change in a patient’s medical status). Regarding Applicant’s remarks regarding the invention being “focused on a particular technical manner of operation”, Examiner submits that using a two-stage, metadata-gated monitoring pipeline (e.g., monitoring metadata for a change, and only upon determination of a change in metadata, requesting full clinical data), falls within the scope of an abstract idea. While the claim recites various additional elements (computing components), these are all understood to be general purpose computing components functioning in their ordinary capacity to implement the steps of the abstract idea. Applicant has not pointed to anything in the claims that fall outside of this characterization. Because the claim elements fall under a series of personal behaviors that a person or persons would follow to monitor a patient’s medical condition and notify family of changes in status, the claimed invention is directed to an abstract idea. This argument is not persuasive.
Amended claim 1 is, at minimum, patent eligible under Step 2A, Prong Two because it
integrates any alleged abstract idea into a practical application that produces a concrete and
demonstrable technical improvement in the operation of a distributed electronic healthcare
monitoring system.
Regarding (D), the Examiner respectfully disagrees. MPEP 2106.04(d)(1) states that a practical application may be present where the claimed invention improves the functioning of a computer. See also MPEP 2106.05(a)(I). The technological environment of Applicant’s claim is general-purpose computing devices (see at least Spec. Para. [0018], [0035]). Applicant has not identified nor can the Examiner locate any physical improvement to the functioning of the computer that results from the implementation of Applicant’s claim. Examiner submits that by implementing a gating step to only transmit data when a metadata comparison affirmatively indicates a change, the amount of data being transmitted is necessarily reduced. Reducing the amount of data based on a change determination will necessarily decrease processing load, minimize data transmitted, and reduce processing burden. There is no indication that the computer itself is made to run faster, more efficiently, or utilize less power. Examiner maintains the position that the claimed invention may provide an improvement to the abstract idea, but does not improve the functioning of the computer itself. Because there is no improvement to the function of the computer, a practical application is not present. MPEP 2106.04(d)(1) also states that a practical application may be present where the claimed invention improves another technology. See also MPEP 2106.05(a)(II). Applicant’s claim is confined to general-purpose computing devices (see at least Spec. Para. [0018], [0035]) and does not recite “another technology.” Because no other technology is recited in the claim, the claim cannot improve another technology (see, e.g., MPEP 2106.05(I)(A)(i) describing an example of an improvement to another technology where the abstract idea implemented on a computer improved the claimed additional element of a rubber molding machine). As such, these additional elements are not improved through implementation of the abstract idea and a practical application is not present. This argument is not persuasive.
Regarding remarks at bottom of page 21 pertaining to “The claim also expressly requires the first electronic device to interact with the clinical data entry system exclusively through standardized API requests and responses without the first electronic device having direct read or write database access permissions to the PHR repository”, Applicant remarks, “These limitations are not ancillary details. They are the very features that implement the
metadata-gated monitoring pipeline and provide the claimed non-interference and low-impact
operation”. Examiner submits that as stated by Applicant, the claimed computing components merely implement the monitoring pipeline to compare data and determine when additional data is warranted. This argument is not persuasive.
Amended claim 1 is closely analogous to USPTO Eligibility Example 40.
Regarding (E), the Examiner respectfully disagrees. While the instant claims may superficially resemble Example 40, Examiner submits that Example 40 was determined to improve the way the machine itself worked, e.g., monitoring the network, and only when a particular condition is met, does it change operation of the machine (when an abnormal condition is present, the system begins collecting NetFlow protocol data). The instant claims are merely monitoring abstract data to determine if more abstract data is needed, e.g., using the first data (metadata) as a trigger condition to obtain additional clinical data only when the metadata comparison warrants an alert, rather than transmitting every individual piece of clinical data. Regarding remarks directed to para. 4 of specification, Examiner respectfully submits that para. 4 does not disclose any background pertaining to problems caused by technological environment of the claim (the computing devices). Claim 4 merely discloses, “Conventional notification processes are not effective for both family members and treatment teams since the only way to notify families during a change in medical status was later in the treatment process. This delay in notification causes unnecessary grief to the family for not being closer to their loved one and allows unnecessary hospital procedures to occur as a result of the delay in notification”. Examiner is unable to see any nexus between a problem disclosed by Claim 4 and an improvement recited by the claims. As discussed in Claim 4, the problem of causing unnecessary grief to family members due to “delay in notification” is not caused by the technological environment of the claim. Examiner maintains the position that using a metadata-gated monitoring only amounts to mere instructions to apply the abstract idea; any purported improvements may be improvements to the abstract idea but are not technological improvements per MPEP 2106.05(a) which states, “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements.” Applicant has not provided, nor can Examiner find evidence of, how any of the additional elements identified above in main 101 analysis section are providing an improvement over prior art systems. The additional elements identified above are understood to be computing components functioning in their normal operating capacity, which is not sufficient to integrate the judicial exception into a practical application. Therefore, this argument is not persuasive.
Amended claim 1 is also consistent with the principles reflected in USPTO Eligibility Example 42.
Regarding (F), the Examiner respectfully disagrees. MPEP 2106.04(d) states that one way in which a claimed abstract idea may be subject matter eligible under prong 2A2 is if the claimed invention solves a described technological problem. Example 42 is an illustration of this. The Specification of Example 42 describes a technical problem (i.e., a problem caused by the technology): the technological implementation of software formats made it difficult to share updated health information. The claimed invention then solved this problem (a technical solution) by providing a message and access to updated real-time data that has been converted to a standardized format, thus integrating the abstract idea into a practical application. Unlike Example 42 and/or the technical solution to a technical problem inquiry, Applicant has not identified nor can the Examiner locate any technical problem that the claimed invention is solving. See above with remarks pertaining to improvement to using meta-data gated monitoring being within the scope of the abstract idea. Therefore, this argument is not persuasive.
The amended claim also directly addresses the concerns previously raised regarding
generic computer implementation.
Regarding (G), the Examiner respectfully disagrees. See above 101 main analysis section for full analysis of additional elements. The computing components are all understood to be general purpose computing components functioning in their ordinary capacities to implement the various steps of the abstract idea. This argument is not persuasive.
These operations are not practically performable in the human mind / Nor is amended claim 1 fairly characterized as a mental process.
Regarding (H), the Examiner respectively submits that the abstract was not characterized as a mental process, nor was it ever stated that the steps of claim 1 could be performed mentally. This argument is not persuasive. Regarding remarks at page 25 pertaining to fixed intervals as short as 100 milliseconds, Examiner submits that the independent claims do not positively recite gathering data at any particular frequency. Further, recitation of gathering data at a particular interval, regardless of frequency, could also be identified as insignificant extra-solution activity in the form of mere data gathering. This argument is not persuasive.
In the alternative, even if the Office were to conclude that amended claim 1 recites a judicial exception, amended claim 1 provides significantly more under Step 2B.
Regarding (I), the Examiner respectfully disagrees. The “ordered combination” analysis pertains to additional elements (MPEP 2106). Applicant has not identified, nor can Examiner find evidence in specification, of how any ordered combination of additional elements in the instant claims amounts to significantly more than the abstract idea. Examiner submits that arguments here have already been addressed in preceding responses. This argument is not persuasive.
For all of the above reasons, the rejections of Claims 1, 11, 20-37 under 35 USC 101 are maintained.
35 USC 103 Rejections
The rejections of Claims 1, 11 and 20 and corresponding dependent claims under 35 USC 103 are withdrawn in view of Applicant’s amendments to the claims. A search of publicly available prior art fails to yield a reference or combination of references that would make all of the claimed combination of the independent claims obvious when considered as a whole.
Conclusion
Examiner respectfully requests that Applicant provides citations to relevant paragraphs of specification for support for amendments in future correspondence.
The following relevant prior art not cited is made of record:
US Publication 20120102502 A1, teaching on managing healthcare information in a distributed system
US Publication 20140088991A1, teaching on a healthcare communication system that facilitates communication between a patient’s healthcare providers and family members
US Publication 20150213202 A1, teaching on a hospital patient care and management system for patient and family engagement
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANNE-MARIE K ALDERSON whose telephone number is (571)272-3370. The examiner can normally be reached on Mon-Fri 9:00am-5:00pm EST, and generally schedules interviews in the timeframe of 2:00-5:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Fonya Long, can be reached on 571-270-5096. 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.
/ANNE-MARIE K ALDERSON/Primary Examiner, Art Unit 3682
Prosecution Insights