DETAILED ACTION
Continued Examination Under 37 CFR 1.114
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 03/10/2026 has been entered.
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 .
Response to Amendment
In light of the amendments, the claims are rejected under 35 U.S.C. 101.
In light of the amendments, the claims are rejected under 35 U.S.C. 103.
Notice to Applicant
In the amendment dated 03/10/2026, the following has occurred: claims 1-2 and 20 have been amended; claims 3-9 and 10-19 remain unchanged; and no new claims have been added.
Claims 1-20 are pending.
Effective Filing Date: 05/20/2021
Response to Arguments
35 U.S.C. 101 Rejections:
Applicant argues that the claims are not directed towards certain methods of organizing human activity. Applicant points to Alice and then states the present claims provide communication of information between a server and a client computer. Applicant further states that a user interface is operating in a certain way with novel data objects to elicit novel responses. Examiner however respectfully disagrees as the claims are indeed directed towards an abstract idea classified under CMOHA. The displaying of data, and in the manner claimed, does not provide a technical improvement as the displaying of information in the claims does not go beyond a mere displaying of data.
Applicant further states that the independent claims define a particular implementation involving network communication, alert generation, and structured graphical user interface interaction. Additionally, Applicant states that the claims cannot practically be performed with pen and paper, and therefore constitute a practical application implemented through a particular computer interface architecture. Examiner however respectfully disagrees as the claims are directed to certain methods of organizing human activity and not mental processes.
Applicant further points out the preamble and states that it does not impose additional structural or functional limitations on the claimed invention, and the body of the claims should be evaluated based on the specific technical operations recited therein. Applicant further points out certain claim limitations and states that the claims are not directed to an abstract idea. Examiner however respectfully disagrees. As stated above, these claim limitations are indeed included as part of an abstract idea.
35 U.S.C. 103 Rejections:
Applicant argues with respect to the amended limitations. These arguments are deemed moot in view of the newly-cited Hamdan et al. reference which was used to teach these limitations.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 1 is drawn to a system, claims 2-19 are drawn to a method, and claim 20 is drawn to an apparatus, each of which is within the four statutory categories. Claims 1-20 are further directed to an abstract idea on the grounds set out in detail below. As discussed below, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea (Step 1: YES).
Step 2A:
Prong One:
Claim 1 recites a system for communicating patient conditions, treatments, and admissions status between health care providers for managing admissions and discharges from hospital care, the system comprising:
a) a patient database on at least one computer server configured for connecting to f) a computer network; and
b) a client application capable of communicating with the patient database over the computer network, the application configured, in response to a determination that an admission status of a patient on a watchlist for e) a client device has changed, to:
1) output an alert on the client device identifying the patient and the status change;
2) display on a display of the client device a list of patients awaiting review, wherein the list of patients is received from the patient database and includes an indication of the patient having the changed admission status;
3) receive, from a user, a selection of a patient from the list of patients;
4) request, at least partly by outputting a checklist of health conditions relevant to an admission status of the patient to a hospital wherein one or more of the health conditions in the checklist are selectable by the user, the user to input one or more conditions of the patient;
5) wherein completion of the checklist causes the client application to automatically generate and transmit a recommendation regarding admission or discharge of the patient to the patient database;
6) request the user to input an admission status comprising a selection from observation or inpatient; and
7) update the patient database with the inputted one or more conditions and admission status.
Claim 1 recites, in part, performing the steps of 1) output an alert identifying the patient and the status change, 2) display a list of patients awaiting review, wherein the list of patients is received from the patient database (where the database is considered to be a piece of paper or a brain storing information) and includes an indication of the patient having the changed admission status, 3) receive, from a user, a selection of a patient from the list of patients, 4) request, at least partly by outputting a checklist of health conditions relevant to an admission status of the patient to a hospital wherein one or more of the health conditions in the checklist are selectable by the user, the user to input one or more conditions of the patient, 5) wherein completion of the checklist causes the client application to automatically generate and transmit a recommendation regarding admission or discharge of the patient, 6) request the user to input an admission status comprising a selection from observation or inpatient, and 7) update the patient database with the inputted one or more conditions and admission status. These steps correspond to Certain Methods of Organizing Human Activity, more particularly, commercial or legal interactions (including agreements in the form of business relations) or managing personal behavior or relationships or interactions between people (including following rules or instructions). For example, the claim describes the management of patient statuses.
Claim 2 recites a method for operating a client device for communicating patient conditions, treatments, and admissions status between health care providers for managing admissions and discharges from hospital care, the method comprising:
7) connecting, by at least e) one processor of the client device, to a) a patient database on at least one computer server via f) a computer network;
8) determining, by the at least one processor, whether an admission status of patient on a watchlist for the client device has changed and if so, outputting an alert on the client device identifying the patient and the status change;
9) displaying on a display of the client device, an identifier of the patient in a list of patients from the patient database;
10) outputting, by the at least one processor, a first input object on the client device for first user input indicating health conditions of the patient, wherein the first input object comprises a checklist of health conditions relevant to an admission or discharge status of the patient to a hospital, and one or more of the health conditions in the checklist are selectable by the first user input;
11) automatically generating, by the at least one processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database;
12) outputting, by the at least one processor, a second input object on the client device for second user input, wherein the second user input indicates a selection of an admission status of the patient or a discharge status of the patient; and
13) providing, by the at least one processor to the patient database, an identifier of a selected patient, the health conditions indicated by the first user input, and the at least one of the admission status or the discharge status of the patient indicated by the second user input.
Claim 2 recites, in part, performing the steps of 7) connecting to a patient database (where the database is considered to be a piece of paper or a brain storing information), 8) determining whether an admission status of patient on a watchlist has changed and if so, outputting an alert identifying the patient and the status change, 9) displaying an identifier of the patient in a list of patients from the patient database, 10) outputting a first input object for first user input indicating health conditions of the patient, wherein the first input object comprises a checklist of health conditions relevant to an admission or discharge status of the patient to a hospital, and one or more health conditions in the checklist are selectable by the first user input, 11) automatically generating, in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation, 12) outputting a second input object for second user input, wherein the second user input indicates a selection of an admission status of the patient or a discharge status of the patient, and 13) providing an identifier of a selected patient, the health conditions indicated by the first user input, and the at least one of the admission status or the discharge status of the patient indicated by the second user input. These steps correspond to Certain Methods of Organizing Human Activity, more particularly, commercial or legal interactions (including agreements in the form of business relations) or managing personal behavior or relationships or interactions between people (including following rules or instructions). For example, the claims describe the management of patient statuses. Independent claim 20 recites similar limitations and is also directed to an abstract idea under the same analysis.
Depending claims 3-19 include all of the limitations of claim 2, and therefore likewise incorporate the above described abstract idea. Depending claim 5 adds the additional step of “displaying details of patient conditions at time of admission to a healthcare facility or at time of discharge from the healthcare facility”; claim 6 adds the additional step of “displaying a list of completed admission alerts by the user of the client device”; claim 7 adds the additional step of “obscuring one or more of the completed admission alerts that are aged more than a defined maximum time interval after creation from display on the client device”; claim 8 adds the additional step of “causing the client device to display an indication that an admissions alert is in a pending status”; claim 9 adds the additional steps of “receiving an indication that the patient is discharged from a healthcare facility” and “closing the admissions alert in response”; claim 10 adds the additional step of “sending a message to a specified electronic address indicating that a new admissions alert is in a pending state”; claim 11 adds the additional step of “configuring the checklist based on a diagnosis record for the patient”; claim 12 adds the additional step of “providing alternative admissions criteria in the checklist for display on the client device”; claim 13 adds the additional step of “determining a recommendation regarding whether the patient should be admitted to a healthcare facility in response to completion of the checklist by the user of the client device”; claim 14 adds the additional step of “processor filtering the list of patients by a third user input indicating one or more healthcare facilities”; claim 16 adds the additional step of “configuring at least one of an alert frequency and type based on a third user input to the client device”; claim 17 adds the additional steps of “receiving a third user input from the client device indicating a selected patient from the list of patients” and “placing an identifier for the selected patient on a watchlist for the client device”; and claim 18 adds the additional steps of “presenting a checklist of discharge criteria concerning the patient for completion by the user of the client device” and “based on completion of the checklist, selecting an indication of an appropriate discharge location type for display on the client device”. Additionally, the limitations of depending claims 3-4, 8, 15, and 19 further specify elements from the claims from which they depend on without adding any additional steps. These additional limitations only further serve to limit the abstract idea. Thus, depending claims 3-19 are nonetheless directed towards fundamentally the same abstract idea as independent claim 2 (Step 2A (Prong One): YES).
Prong Two:
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of – using a) a patient database on at least one computer server and b) a client application capable of communicating with the patient database, c) at least one processor (from claim 20) coupled to d) an electronic memory (from claim 20), e) a client device with a display and at least one processor, and f) a computer network to perform the claimed steps.
The a) a patient database and b) a client application, c) at least one processor coupled to d) an electronic memory, and f) computer network in these steps are recited at a high-level of generality (i.e., as generic components performing generic computer functions) such that it amount to no more than mere instructions to apply the exception using generic computer components (see: Applicant’s specification, paragraph [0094] where there is a general purpose processor, paragraph [0094] where there is a generic memory (which would also apply to a computerized database and application, and paragraph [0042] where there is a generic network), see MPEP 2106.05(f)).
The e) client device with a display and at least one processor in these steps adds insignificant extra-solution activity to the abstract idea which amounts to mere data gathering, see MPEP 2106.05(g).
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims. Looking at the limitations 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 and do not impose a meaningful limit to integrate the abstract idea into a practical application.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea (Step 2A (Prong Two): NO).
Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a) a patient database and b) a client application capable of communicating with the patient database, c) at least one processor coupled to d) an electronic memory, e) a client device with a display and at least one processor, and f) a computer network to perform the claimed steps amounts to no more than insignificant extra-solution activity in the form of WURC activity (well-understood, routine, and conventional activity) and or mere instructions to apply the exception using generic computer components that do not offer “significantly more” than the abstract idea itself because the claims do not recite an improvement to another technology or technical field, an improvement to the functioning of any computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. It should be noted that the claims do not include additional elements that amount to significantly more than the judicial exception because the Specification recites mere generic computer components, as discussed above that are being used to apply certain method steps of organizing human activity. Specifically, MPEP 2106.05(d) and MPEP 2106.05(f) recite that the following limitations are not significantly more:
Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d)); and
Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 134 S. Ct. at 2360, 110 USPQ2d at 1984 (see MPEP § 2106.05(f)).
The current invention updates a patient database utilizing a) a patient database (stored on a computer) and b) a client application capable of communicating with the patient database and the current invention also provides status information on a patient utilizing, c) at least one processor coupled to d) an electronic memory, and f) a computer network, thus these components are adding the words “apply it” with mere instructions to implement the abstract idea on a computer.
Furthermore, the e) client device with a display and at least one processor in these steps add insignificant extra-solution activity/pre-solution activity in the form of WURC activity to the abstract idea. The following is an example of a court decision demonstrating computer functions as well-understood, routine and conventional activities, e.g. see MPEP 2106.05(d)(II): Receiving or transmitting data over a network, e.g. see Intellectual Ventures v. Symantec – similarly, the current invention receives client device data, and transmits the data to a system over a network, for example the Internet. Additionally, the current invention receives data regarding a list of patients, and transmits the data to a client device over a network, for example the Internet.
Mere instructions to apply an exception using generic computer components or insignificant extra-solution activity in the form of WURC activity cannot provide an inventive concept. The claims are not patent eligible (Step 2B: NO).
Claims 1-20 are therefore rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-6, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. and further in view of U.S. 2015/0169835 to Hamdan et al.
As per claim 1, Whannel et al. teaches a system for communicating patient conditions, treatments, and admissions status between health care providers for managing admissions and discharges from hospital care, the system comprising:
--a patient database on at least one computer server configured for connecting to a computer network; (see: paragraph [0041] where there is a patient database on a server. Also see: paragraph [0081] where the network is used to connect devices and servers where the servers contain the databases (see: paragraph [0082]). The database here is configured to connect to the network here) and
--a client application capable of communicating with the patient database over the computer network, (see: paragraph [0041] where there is interactivity between a mobile computing device (client device) and a server (which contains the patient database). Also see: paragraph [0082] where there is a network that is being used to enable communication between the device and the database. The device here has a platform (application) capable of communicating with the database), the application configured, in response to a determination that a status of a patient on a watchlist for a client device has changed, (see: paragraphs [0099] and [0100] where there is an alert which is sent after determining that a patient field values have changed) to:
--output an alert on the client device identifying the patient and the status change; (see: paragraphs [0099] and [0100] where there is an outputted alert on a device about the patient and their status change, where the status change is related to the updated patient data which is outside of a range)
--display on a display of the client device a list of patients awaiting review, (see: FIGS. 5 and 30 where there is a display of a list of patients on a client device. Also see: paragraph [0089] where a program status for patient may be listed. The list here is being displayed on a phone which can include patients of various program statuses, including “admitted” and “discharged” as explained in paragraph [0070]) wherein the list of patients is received from the patient database; (see: paragraph [0108] where a user can click and access the patient data of FIG. 30 from the patient database)
--receive, from a user, a selection of a patient from the list of patients; (see: FIG. 5 and FIGS. 20-21 and paragraph [0103] where there is a selection of Ben Franklin in FIG. 5 and the selection is confirmed via showing the patient information in FIGS. 20-21. Also see: paragraph [0090] where there is a description of clicking 405 from a list of patients on FIG. 5 to go to FIG. 6)
--request, at least partly by outputting a checklist of conditions relevant to an admission status of the patient to a hospital wherein one or more of the conditions in the checklist are selectable by the user, the user to input one or more conditions of the patient; (see: FIG. 7 and paragraph [0092] where there is an option to log a visit. Medication information may be edited here. Also see: FIG. 14 where after the visit a log is created and the user can input the patients vital data (their condition). Thus, the user here is being requested to log a condition of the patient. Also see: paragraph [0075] where there is a checklist which is used to help assess a patient during a visit. The checklist is about conditions of the patient with respect to the admission status of the patient. The checklist is being output and input information is being requested, and conditions on this checklist are selectable by the user to input information)
--request the user to input an admission status comprising a selection from observation or inpatient; (see: paragraph [0070] where there is a program status for each patient such as re-hospitalization or placed (inpatient or observation) or various other program statuses. A status is being changed by the user. Also see: paragraph [0072] where the program status may be updated or created. A request is being provided here to input/confirm the program status (admission status) of the patient) and
--update the patient database with the inputted one or more conditions and admission status (see: paragraph [0020] where the program status is being updated, and therefore the patient database is being updated. Also see: FIG. 7 and paragraph [0072] where there is an updating of patient information including a log of a visit).
In the above embodiment of Whannel et al., Whannel et al. may not further, specifically teach:
--status as an admission status.
In one embodiment of Whannel et al. however, it is taught that there is alerting of inconsistencies in information between medical visits (see: paragraph [0008]). While in another embodiment of Whannel et al. it is taught that there are changes in the patient’s program status as the inconsistencies (see: paragraphs [0069] and [0070]).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute an admission status as the changed data as taught by one embodiment of Whannel et al. for the changed data which causes the alert as disclosed by another embodiment of Whannel et al. since each individual element and its function are shown in the prior art, with the difference being the substitution of the elements. In the present case, Whannel et al. already teaches of the functionality of alerting based on changed data thus one could substitute the type of changed data which creates an alert to obtain predictable results of alerting based on changed data. Thus, one of ordinary skill in the art could have substituted the one known element for the other to produce a predictable result (MPEP 2143).
Whannel et al. may not further, specifically teach:
1) --wherein the list of patients includes an indication of the patient having the changed admission status;
2) --wherein completion of the checklist causes the client application to automatically generate and transmit a recommendation regarding admission or discharge of the patient to the patient database; and
3) --conditions as health conditions.
Harber et al. teaches:
1) --wherein the list of patients includes an indication of the patient having the changed admission status (see: paragraphs [0033] and [0051] where there is an alert which visually distinguishes patients who have a changed admission status such as not having a status to having an admission status).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the list of patients includes an indication of the patient having the changed admission status as taught by Harber et al. in the system as taught by Whannel et al. with the motivation(s) of making improved and informed decisions in real time (see: paragraph [0023] of Harber et al.).
Hamdan et al. teaches:
2) --wherein completion of the checklist causes the client application to automatically generate and transmit a recommendation regarding admission or discharge of the patient to the patient database; (see: paragraph [0040] where such a recommendation generation process is occurring using inputted data. Also see: paragraphs [0013] and [0110] where there is transmission of the recommendation to a device) and
3) --conditions as health conditions (see: paragraphs [0009] and [0051] where there are medical conditions for the conditions).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have 2) wherein completion of the checklist causes the client application to automatically generate and transmit a recommendation regarding admission or discharge of the patient to the patient database as taught by Harber et al. in the system as taught by Whannel et al. with the motivation(s) of improving patient care while lowering overall healthcare costs (see: paragraph [0035] of Hamdan et al.).
Furthermore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute 3) health conditions as taught by Hamdan et al. for the conditions as disclosed by Whannel et al. and Harber et al. in combination since each individual element and its function are shown in the prior art, with the difference being the substitution of the elements. In the present case, the combination of Whannel et al. and Harber et al. already teaches of conditions in a broad sense in reference to an assessment thus one can replace those conditions with other conditions and achieve predictable results of using conditions when assessing a patient. Thus, one of ordinary skill in the art could have substituted the one known element for the other to produce a predictable result (MPEP 2143).
As per claim 2, Whannel et al. teaches a method for operating a client device for communicating patient conditions, treatments, and admissions status between health care providers for managing admissions and discharges from hospital care, the method comprising:
--connecting, by at least one processor of the client device, to a patient database on at least one computer server via a computer network; (see: paragraph [0041] where there is a patient database on a server. Also see: paragraph [0081] where the network is used to connect devices and servers where the servers contain the databases (see: paragraph [0082]). The database here is configured to connect to the network here)
--outputting an alert on the client device identifying the patient and the status change; (see: paragraphs [0099] and [0100] where there is an outputted alert on a device about the patient and their status change, where the status change is related to the updated patient data which is outside of a range)
--displaying on a display of the client device, an identifier of the patient in a list of patients from the patient database; (see: FIGS. 5 and 30 where there is a display of a list of patients on a client device. Each patient’s name on the display is the identifier of that patient. Also see: paragraph [0089] where a program status for patient may be listed. The list here is being displayed on a phone which can include patients of various program statuses, including “admitted” and “discharged” as explained in paragraph [0070]. Also see: paragraph [0108] where a user can click and access the patient data of FIG. 30 from the patient database)
--outputting, by the at least one processor, a first input object on the client device for first user input indicating conditions of the patient, (see: FIG. 7 and paragraph [0092] where there is an option to log a visit. Medication information may be edited here. Also see: FIG. 14 where after the visit log is created the user can input the patients vital data (their condition). Thus, the user here is being requested to log a conditions of the patient. This information is being displayed by an input object/graphical representation on a display (first input object)) wherein the first input object comprises a checklist of conditions relevant to an admission or discharge status of the patient to a hospital, (see: paragraph [0075] where there is a checklist which is used to help assess a patient during a visit. The checklist is about conditions of the patient with respect to the admission status of the patient. The checklist is being output and input information is being requested) and one or more of the conditions in the checklist are selectable by the first user input; (see: paragraph [0075] where there is a checklist which is used to help assess a patient during a visit. The checklist is about conditions of the patient with respect to the admission status of the patient. The checklist is being output and input information is being requested, and conditions on this checklist are selectable by the user to input information)
--outputting, by the at least one processor, a second input object on the client device for second user input, wherein the second user input indicates a selection of an admission status of the patient or a discharge status of the patient; (see: paragraph [0070] where there is a program status for each patient such as admitted (admission) or discharged (discharged) or various other program statuses. A status is being changed by the user. Also see: paragraph [0072] where the program status may be updated or created. A request is being provided here to confirm the program status (admission status) of the patient. This information is being displayed/outputted by an input object/graphical representation on a display (second input object)) and
--providing, by the at least one processor to the patient database, an identifier of the selected patient, the conditions indicated by the first user input, and the at least one of the admission status or the discharge status of the patient indicated by the second user input (see: paragraph [0020] where the program status is being updated, and therefore the patient database is being updated. Also see: FIG. 7 and paragraph [0072] where there is an updating of patient information including a log of a visit. Also see: FIG. 5 where information is being retrieved from a patient database. This information includes an identifier (the patient’s name in FIG. 5), the updated patient information such as the ones associated with the program type (the user health condition), and the program status of the patient (admission or discharge status). Therefore, this information is being provided to the patient database upon update, in order for this data to then be displayed).
Whannel et al. may not further, specifically teach:
1) --determining, by the at least one processor, whether an admission status of patient on a watchlist for the client device has changed and if so, outputting an alert;
2) --automatically generating, by the at least one processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database; and
3) --conditions as health conditions.
Harber et al. teaches:
1) --determining, by the at least one processor, whether an admission status of patient on a watchlist for the client device has changed and if so, outputting an alert (see: paragraphs [0033] and [0051] where there is an alert which visually distinguishes patients who have a changed admission status such as not having a status to having an admission status. This alert is done after a determination of an admission status has changed).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to determine, by the at least one processor, whether an admission status of patient on a watchlist for the client device has changed and if so, outputting an alert as taught by Harber et al. in the method as taught by Whannel et al. with the motivation(s) of making improved and informed decisions in real time (see: paragraph [0023] of Harber et al.).
Hamdan et al. teaches:
2) --automatically generating, by the at least one processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database; (see: paragraph [0040] where such a recommendation generation process is occurring using inputted data. Also see: paragraphs [0013] and [0110] where there is transmission of the recommendation to a device) and
3) --conditions as health conditions (see: paragraphs [0009] and [0051] where there are medical conditions for the conditions).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to 2) automatically generate, by the at least one processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database as taught by Harber et al. in the method as taught by Whannel et al. with the motivation(s) of improving patient care while lowering overall healthcare costs (see: paragraph [0035] of Hamdan et al.).
Furthermore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute 3) health conditions as taught by Hamdan et al. for the conditions as disclosed by Whannel et al. and Harber et al. in combination since each individual element and its function are shown in the prior art, with the difference being the substitution of the elements. In the present case, the combination of Whannel et al. and Harber et al. already teaches of conditions in a broad sense in reference to an assessment thus one can replace those conditions with other conditions and achieve predictable results of using conditions when assessing a patient. Thus, one of ordinary skill in the art could have substituted the one known element for the other to produce a predictable result (MPEP 2143).
As per claim 5, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. Whannel et al. further teaches further comprising by the at least one processor displaying details of patient conditions at time of admission to a healthcare facility or at time of discharge from the healthcare facility (see: FIG. 5 where part of the condition of the patient is being displayed in the form of a program type at time of discharge).
As per claim 6, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. Whannel et al. further teaches further comprising by the at least one processor displaying a list of completed admission alerts by the user of the client device (see: paragraph [0070] where the program status can be “admitted”. Also see: Fig. 5 where there is a display of completed admission alerts in the form of displayed program statuses).
As per claim 16, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. Whannel et al. further teaches further comprising configuring at least one of an alert frequency and type based on a third user input to the client device (see: paragraph [0036] where an alert is generated when the physiological measurement is outside of a first range. Also see: paragraph [0035] where information is being entered including physiological measurement data).
As per claim 20, Whannel et al. teaches an apparatus for assisting a user with communicating patient conditions, treatments, and admissions status between health care providers for managing admissions and discharges from hospital care, the apparatus comprising a processor coupled to an electronic memory, the memory holding instructions that when executed by the processor cause the apparatus to perform:
--connecting to a patient database on at least one computer server via a computer network; (see: paragraph [0041] where there is a patient database on a server. Also see: paragraph [0081] where the network is used to connect devices and servers where the servers contain the databases (see: paragraph [0082]). The database here is configured to connect to the network here)
--outputting an alert on the client device identifying the patient and the status change; (see: paragraphs [0099] and [0100] where there is an outputted alert on a device about the patient and their status change, where the status change is related to the updated patient data which is outside of a range)
--displaying on a display of the client device, an identifier of the patient in a list of patients from the patient database; (see: FIGS. 5 and 30 where there is a display of a list of patients on a client device. Each patient’s name on the display is the identifier of that patient. Also see: paragraph [0089] where a program status for patient may be listed. The list here is being displayed on a phone which can include patients of various program statuses, including “admitted” and “discharged” as explained in paragraph [0070]. Also see: paragraph [0108] where a user can click and access the patient data of FIG. 30 from the patient database)
--outputting a first input object on the client device for first user input indicating conditions of the patient, (see: FIG. 7 and paragraph [0092] where there is an option to log a visit. Medication information may be edited here. Also see: FIG. 14 where after the visit log is created the user can input the patients vital data (their condition). Thus, the user here is being requested to log a conditions of the patient. This information is being displayed by an input object/graphical representation on a display (first input object)) wherein the first input object comprises a checklist of conditions relevant to an admission or discharge status of the patient to a hospital (see: paragraph [0075] where there is a checklist which is used to help assess a patient during a visit. The checklist is about conditions of the patient with respect to the admission status of the patient. The checklist is being output and input information is being requested) and one or more of the conditions in the checklist are selectable by the first user input; (see: paragraph [0075] where there is a checklist which is used to help assess a patient during a visit. The checklist is about conditions of the patient with respect to the admission status of the patient. The checklist is being output and input information is being requested, and conditions on this checklist are selectable by the user to input information)
--outputting a second input object on the client device for second user input, wherein the second user input indicates a selection of an admission status of the patient or a discharge status of the patient; (see: paragraph [0070] where there is a program status for each patient such as admitted (admission) or discharged (discharged) or various other program statuses. A status is being changed by the user. Also see: paragraph [0072] where the program status may be updated or created. A request is being provided here to confirm the program status (admission status) of the patient. This information is being displayed by an input object/graphical representation on a display (second input object)) and
--providing to the patient database an identifier of a selected patient, the conditions indicated by the first user input, and the at least one of the admission status or the discharge status of the patient indicated by the second user input (see: paragraph [0020] where the program status is being updated, and therefore the patient database is being updated. Also see: FIG. 7 and paragraph [0072] where there is an updating of patient information including a log of a visit. Also see: FIG. 5 where information is being retrieved from a patient database. This information includes an identifier (the patient’s name in FIG. 5), the updated patient information such as the ones associated with the program type (the user health condition), and the program status of the patient (admission or discharge status). Therefore, this information is being provided to the patient database upon update, in order for this data to then be displayed).
Whannel et al. may not further, specifically teach:
1) --determining, by the at least one processor, whether an admission status of patient on a watchlist for a client device has changed and if so, outputting an alert;
2) --automatically generating, by the processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database; and
3) --conditions as health conditions.
Harber et al. teaches:
1) --determining, by the at least one processor, whether an admission status of patient on a watchlist for a client device has changed and if so, outputting an alert (see: paragraphs [0033] and [0051] where there is an alert which visually distinguishes patients who have a changed admission status such as not having a status to having an admission status. This alert is done after a determination of an admission status has changed).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to determine, by the at least one processor, whether an admission status of patient on a watchlist for a client device has changed and if so, outputting an alert as taught by Harber et al. in the apparatus as taught by Whannel et al. with the motivation(s) of making improved and informed decisions in real time (see: paragraph [0023] of Harber et al.).
Hamdan et al. teaches:
2) --automatically generating, by the processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database; (see: paragraph [0040] where such a recommendation generation process is occurring using inputted data. Also see: paragraphs [0013] and [0110] where there is transmission of the recommendation to a device) and
3) --conditions as health conditions (see: paragraphs [0009] and [0051] where there are medical conditions for the conditions).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to 2) automatically generate, by the processor in response to completion of the checklist by the first user input, a recommendation regarding admission or discharge of the patient and transmitting the recommendation to the patient database as taught by Harber et al. in the apparatus as taught by Whannel et al. with the motivation(s) of improving patient care while lowering overall healthcare costs (see: paragraph [0035] of Hamdan et al.).
Furthermore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute 3) health conditions as taught by Hamdan et al. for the conditions as disclosed by Whannel et al. and Harber et al. in combination since each individual element and its function are shown in the prior art, with the difference being the substitution of the elements. In the present case, the combination of Whannel et al. and Harber et al. already teaches of conditions in a broad sense in reference to an assessment thus one can replace those conditions with other conditions and achieve predictable results of using conditions when assessing a patient. Thus, one of ordinary skill in the art could have substituted the one known element for the other to produce a predictable result (MPEP 2143).
Claims 3-4 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. and further in view of U.S. 2015/0169835 to Hamdan et al. as applied to claim 2, and further in view of U.S. 2015/0356701 to Gandy et al.
As per claim 3, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. The combination may not further, specifically teach by the at least one processor determining that an admission status of patient on a watchlist for the client device has changed and outputting an admissions alert on the client device identifying the patient and the status change.
Gandy et al. teaches:
--by the at least one processor determining that an admission status of patient on a watchlist for the client device has changed (see: paragraph [0076] where there are trigger threshold which, when reached, notify caregivers. The patient here is on a watchlist and their status is being changed) and outputting an admissions alert on the client device identifying the patient and the status change (see: paragraph [0076] where there are trigger threshold which, when reached, notify caregivers. The patient here is on a watchlist and their status is being changed. The change is being displayed here to the caregiver where the patients (names) are being displayed with in their classifications (status)).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to, by the at least one processor, determine that an admission status of patient on a watchlist for the client device has changed and outputting an admissions alert on the client device identifying the patient and the status change as taught by Gandy et al. in the method as taught by Whannel et al., Harber et al., and Hamdan et al. in combination with the motivation(s) of improving an adherence level of a patient to a regimen (see: paragraph [0009] of Gandy et al.) as Whannel et al. discusses treatment of a patient in paragraph [0007].
As per claim 4, Whannel et al., Harber et al., Hamdan et al., and Gandy et al. in combination teaches the method of claim 3, see discussion of claim 3. Whannel et al. further teaches wherein the determining and the outputting the admissions alert are preconditions to performing all steps of claim 2 (see: claim 2 which is taught by Whannel et al. Also see: FIG. 5 where a patient list is being displayed with the updated status of the patient. Admissions information here is done prior to the claimed steps of claim 2, thus the admissions steps of the Gandy et al. reference would also be considered as admissions steps and therefore could also be done before the steps of claim 2).
As per claim 17, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. Whannel et al. further teaches by the at least one processor receiving a third user input from the client device indicating a selected patient from the list of patients (see: FIGS. 5-9 where FIG. shows a list of patients and then FIGS. 6-9 shows information for a selected patient. Also see: paragraph [0108] where a patient is selected from a list via clicking).
Whannel et al., Harber et al., and Hamdan et al. in combination may not further, specifically teach placing an identifier for the selected patient on a watchlist for the client device.
Gandy et al. teaches:
--placing an identifier for the selected patient on a watchlist for the client device (see: paragraph [0076] where the patient (the name of the patient which is the identifier) is placed on a watchlist).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to place an identifier for the selected patient on a watchlist for the client device as taught by Gandy et al. in the method as taught by Whannel et al., Harber et al., and Hamdan et al. in combination with the motivation(s) of facilitating management of a patient by tracking them (see: paragraph [0076] of Gandy et al.).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. and further in view of U.S. 2015/0169835 to Hamdan et al. as applied to claim 6, and further in view of U.S. 2016/0345874 to Raisoni et al.
As per claim 7, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 6, see discussion of claim 6. The combination may not further, specifically teach by the at least one processor obscuring one or more of the completed admission alerts that are aged more than a defined maximum time interval after creation from display on the client device.
Raisoni et al. teaches:
--further comprising by the at least one processor obscuring ones of the completed admission alerts that are aged more than a defined maximum time interval after creation from display on the client device (see: paragraph [0336] where a notification is being removed after a predetermined period of time from a display).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to, by the at least one processor, obscure ones of the completed admission alerts that are aged more than a defined maximum time interval after creation from display on the client device as taught by Raisoni et al. in the method as taught by Whannel et al., Harber et al., and Hamdan et al. in combination with the motivation(s) of factoring in when a user defers information to be displayed (see: paragraph [0336] of Raisoni et al.).
Claims 8-9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. and further in view of U.S. 2015/0169835 to Hamdan et al. as applied to claim 2, and further in view of U.S. 2015/0294089 to Nichols.
As per claim 8, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. The combination does not further, specifically teach by the at least one processor, causing the client device to display an indication that an admissions alert is in a pending status.
Nichols teaches:
--by the at least one processor, causing the client device to display an indication that an admissions alert is in a pending status (see: paragraph [0056] where an admission to a lab test for the patient is pending when the technician looks at the patient).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to, by the at least one processor, cause the client device to display an indication that an admissions alert is in a pending status as taught by Nichols in the method as taught by Whannel et al., Harber et al., and Hamdan et al. in combination with the motivation(s) of facilitating an improved interaction between a user and a patient (see: paragraph [0008] of Nichols).
As per claim 9, Whannel et al., Harber et al., Hamdan et al., and Nichols in combination teaches the method of claim 8, see discussion of claim 8. Nichols further teaches further comprising by the at least one processor receiving an indication that the patient is discharged from a healthcare facility, and closing the admissions alert in response (see: paragraph [0057] where the panel 512 shows that the technician’s work is complete the patient thanks the technician. Thus, when the patient is being discharged, the system here would also conclude when the technician’s work is completed at the point of discharge. All alerts would be removed from the display as shown in FIG. 5B).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1, and incorporated herein.
As per claim 11, Whannel et al., Harber et al., Hamdan et al., and Nichols in combination teaches the method of claim 8, see discussion of claim 8. Whannel et al. further teaches further comprising by the at least one processor configuring the checklist based on a diagnosis record for the patient (see: paragraph [0075] where the generated checklist is based on a diagnosis of a patient such that a home assessment or a falls assessment would be required).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. further in view of U.S. 2015/0169835 to Hamdan et al. further in view of U.S. 2015/0294089 to Nichols as applied to claim 8, and further in view of U.S. 2013/0173287 to Cashman et al.
As per claim 10, Whannel et al., Harber et al., Hamdan et al., and Nichols in combination teaches the method of claim 8, see discussion of claim 8. Harber et al. further teaches by the at least one processor, sending a message to a specified electronic address (see: paragraph [0051] where there is sending of a notification to a clinician’s mobile application).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1, and incorporated herein.
Whannel et al., Harber et al., Hamdan et al., and Nichols in combination may not further, specifically teach:
--a message indicating that a new admissions alert is in a pending state.
Cashman et al. teaches:
--a message indicating that a new admissions alert is in a pending state (see: paragraph [0020] where there is a pending appointment status indication).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have a message indicating that a new admissions alert is in a pending state as taught by Cashman et al. in the method as taught by Whannel et al., Harber et al., Hamdan et al., and Nichols in combination with the motivation(s) of monitoring the status of an appointment (see: paragraph [0017] of Cashman et al.).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. further in view of U.S. 2015/0169835 to Hamdan et al. further in view of U.S. 2015/0294089 to Nichols as applied to claims 8 and 11, and further in view of U.S. 2015/0317440 to Brock-Utne.
As per claim 12, Whannel et al., Harber et al., Hamdan et al., and Nichols in combination teaches the method of claim 11, see discussion of claim 11. The combination may not further, specifically teach wherein the configuring comprises providing alternative admissions criteria in the checklist for display on the client device.
Brock-Utne teaches:
--wherein the configuring comprises providing alternative admissions criteria in the checklist for display on the client device (see: paragraph [0082] where there is an interactive, pre-operative checklist. There are alternative admissions criteria which are being displayed in the form of certain medical problems).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the configuring comprises providing alternative admissions criteria in the checklist for display on the client device as taught by Brock-Utne in the method as taught by Whannel et al., Harber et al., Hamdan et al., and Nichols in combination with the motivation(s) of improving the quality and efficiencies in healthcare facilities (see: paragraph [0003] of Brock-Utne).
As per claim 13, Whannel et al., Harber et al., Hamdan et al., and Nichols in combination teaches the method of claim 8, see discussion of claim 8. The combination may not further, specifically teach by the at least one processor determining a recommendation regarding whether the patient should be admitted to a healthcare facility in response to completion of the checklist by the user of the client device.
Brock-Utne teaches:
--by the at least one processor determining a recommendation regarding whether the patient should be admitted to a healthcare facility in response to completion of the checklist by the user of the client device (see: paragraph [0052] where there are indicators at the top of each screen and turn green when ready. There is a determined recommendation for OR ready (admission ready) in response to a completed checklist).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to, by the at least one processor, determine a recommendation regarding whether the patient should be admitted to a healthcare facility in response to completion of the checklist by the user of the client device as taught by Brock-Utne in the method as taught by Whannel et al., Harber et al., Hamdan et al., and Nichols in combination with the motivation(s) of improving the quality and efficiencies in healthcare facilities (see: paragraph [0003] of Brock-Utne).
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. and further in view of U.S. 2015/0169835 to Hamdan et al. as applied to claim 2, and further in view of U.S. 2008/0263477 to Ying et al.
As per claim 14, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. The combination may not further, specifically teach by the at least one processor filtering the list of patients by a third user input indicating one or more healthcare facilities.
Ying et al. teaches:
--by the at least one processor filtering the list of patients by a third user input indicating one or more healthcare facilities (see: paragraph [0044] where there is a sorting of patients by medical facility).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to, by the at least one processor, filter the list of patients by a third user input indicating one or more healthcare facilities as taught by Ying et al. in the method as taught by Whannel et al., Harber et al., and Hamdan et al. in combination with the motivation(s) of preventing access to patient information from being time consuming and difficult (see: paragraph [0003] of Ying et al.).
As per claim 15, Whannel et al., Harber et al., Hamdan et al., and Ying et al. in combination teaches the method of claim 14, see discussion of claim 14. Whannel et al. further teaches wherein the third user input is by a different user entered on a different device in communication with the client device (see: paragraph [0081] where there may be a computing device of another enterprise user).
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0196387 to Whannel et al. in view of U.S. 2016/0070863 to Harber et al. and further in view of U.S. 2015/0169835 to Hamdan et al. as applied to claim 2, and further in view of U.S. Patent No. 10,679,746 to Fletcher et al. in view of U.S. 2013/0304511 to Gunter.
As per claim 18, Whannel et al., Harber et al., and Hamdan et al. in combination teaches the method of claim 2, see discussion of claim 2. The combination may not further, specifically teach by the at least one processor presenting a checklist of discharge criteria concerning the patient for completion by the user of the client device, and based on completion of the checklist, selecting an indication of an appropriate discharge location type for display on the client device.
Fletcher et al. teaches:
--by the at least one processor presenting a checklist of discharge criteria concerning the patient for completion by the user of the client device, (see: column 16, lines 55-62 where there is presentation of a checklist of milestones to be completed in order to discharge) and based on completion of the checklist, selecting an indication for display on the client device (see: column 16, lines 55-62 where there is a selection of an indication in response to a completion of the checklist in the form of a scheduled appointment).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to, by the at least one processor, present a checklist of discharge criteria concerning the patient for completion by the user of the client device, and based on completion of the checklist, select an indication for display on the client device as taught by Fletcher et al. in the method as taught by Whannel et al., Harber et al., and Hamdan et al. in combination with the motivation(s) of improving coordination of care (see: column 2, lines 15-18 of Fletcher et al.).
Gunter teaches:
--an indication of an appropriate discharge location type for display on the client device (see: paragraph [0060] where there is an indication of a discharge location being displayed as a notification).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to use an indication of an appropriate discharge location type for display on the client device as taught by Gunter in the method as taught by Whannel et al., Harber et al., Hamdan et al., and Fletcher et al. in combination with the motivation(s) of providing a secure and easy way to log and track transitions of a patient between providers (see: paragraph [0002] of Gunter).
As per claim 19, Whannel et al., Harber et al., Hamdan et al., Fletcher et al., and Gunter in combination teaches the method of claim 18, see discussion of claim 18. Gunter further teaches wherein appropriate discharge location type is based at least in part on a geographic location of the patient (see: paragraph [0060] where geographical location (GPS) is factored for the discharge location).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 18, and incorporated herein.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Steven G.S. Sanghera whose telephone number is (571)272-6873. The examiner can normally be reached M-F 7:30-5:00 (alternating Fri).
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, Shahid Merchant can be reached on (571) 270-1360. 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.
/STEVEN G.S. SANGHERA/Primary Examiner, Art Unit 3684
Prosecution Insights