Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Priority
Applicant’s claim for the benefit of prior-filed applications under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c), 17/080,094, 15/049,949, 13/835,406, and 12/987,252, is acknowledged.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 10,854,320. Although the claims at issue are not identical, they are not patentably distinct from each other because each of the limitations recited in claims 1-21 of the instant application are also recited in claims 1-20 of the ‘320 patient. The differences are only found in additional limitations, arrangement of the recitations, and cosmetic differences recited in claims 1-20 of the ’320 patent which do not patentably distinguish the instant claims from those of the ‘320 patent.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-6 and 11-12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “receiving one of the plurality of general event descriptors.” There are no previous recitations of “general event descriptors.” Therefore, this recitation lacks sufficient antecedent basis in the claim.
Claims 2-6 are rejected based on their dependencies on claim 1.
Claims 11 and 12 recite “The method of claim 6…” Claim 6 is directed to a “computer system of claim 1.” Therefore, referring to “the method” of claim 6” is unclear and indefinite. It appears that these claims should depend on claim 7 and, for examination purposes, will be treated as such.
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-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A Prong One
Claims 1 recites receive commands to access a patient chart in the patient records database and provide access to the patient chart on the display; present an electronic message icon on the display of the patient chart; display a message template on the display, the message template including a target field and a message field; receive one of the plurality of general event descriptors in the target field; identify a message format for a message corresponding to the one of the plurality of general event descriptors, the message format defining a plurality of fields for contextual patient data in the message field; populate at least one of the plurality of fields for contextual data with patient data from the patient chart; identify at least one recipient of the message based on the general event descriptor; and transmit the message to the identified at least one recipient.
Claim 7 recites receiving input identifying a patient in the electronic medical records system via an interface and presenting a patient chart on a display; providing a message icon on the display; presenting a message template on the display, wherein the message template includes at least one target field configured to receive a general event descriptor and at least one message field; receiving the general event descriptor in the target message field and using the general event descriptor to identify a message format identifying a plurality of fields for contextual data corresponding to the patient in a message field; accessing the patient chart and populating at least one of the plurality of fields for contextual data with data from the chart; using the general event descriptor to identify at least one recipient of the message; transmitting the message to the at least one recipient and requesting the at least one recipient to begin a workflow corresponding to the general event descriptor.
Claim 13 recites receive a command to access a patient chart; present the patient chart on the display; present an electronic message icon on the display; present a message template on the display, the message template including a target field and a message field; receive a general event descriptor in the target field and utilize the general event descriptor to format a message entered into the message field, the message comprising a plurality of contextual data fields for receiving contextual data corresponding to the patient chart; retrieve data from the patient chart to populate the contextual data fields; identify a workflow to be performed based on at least one of the general event descriptor and the contextual data in the contextual data fields; identify a recipient based on the identified workflow; and transmit the message to the identified recipient.
These limitations, as drafted, given the broadest reasonable interpretation, encompass managing interactions between people, which is a subgrouping of Certain Methods of Organizing Human Activity. Additionally, certain activities between a person and a computer falls within this subgrouping of Certain Methods of Organizing Human Activity (MPEP 2016.04(a)(2)II). For example, the claims encompass accessing a patient chart in patient records, providing a message template including target and message fields, receiving a general event descriptor in the target field, and using this information to format a message populated with the fields and data from the patient chart, identifying someone to receive the message and transmitting the message to that individual. These steps could be carried out manually between users in the process of creating messages related to patient chart information and providing the messages to appropriate recipients. Such manual steps encompass Certain Methods of Organizing Human Activity.
Claims 2-6, 8-12 and 14-21 incorporate the abstract idea identified above and recite additional limitations that expand on the abstract idea. For example, claims 2, 11, and 16 further expand on the general event descriptor. Claims 3-4, 8-9, and 15 further recite entity capabilities to identify the recipient for providing the workflow. These steps further define the steps being caried out between individuals. Claims 5-6, and 14 further expand on the workflow. Claims 10 and 20 further expand on the identifying of an entity. Claims 12, 17, and 19 further expand on the patient information included in the message. Claim 28 further recites an additional field for information in the message. Claim 21 further expands on the contextual data. As explained above, these manual steps encompass Certain Methods of Organizing Human Activity.
Step 2A Prong Two
This judicial exception is not integrated into a practical application because the remaining elements amount to no more than general purpose computer components programmed to perform the abstract ideas along with adding elements similar to adding the words “apply it” to the abstract idea, and generally linking the abstract idea to a particular technological environment, along with insignificant, extra-solution data gathering activity.
Claims 1-21, directly or indirectly, recite the following additional elements at a high level of generality and merely utilized as tools to implement the abstract idea:
Claim 1:
a patient records database, the patient records database comprising patient charts corresponding to each of a plurality of patients; a user interface including a display; and a processor in communication with the patient records database and the user interface, the processor programmed.
upon activation of the electronic message icon.
messages being “electronic.”
Claim 7:
providing a processor programmed to perform the steps.
upon activation of the electronic message icon.
messages being “electronic.”
Claim 13:
a database comprising a plurality of patient charts, each patient chart including patient medical records for an associated patient, the patient medical records including pre-defined fields; a user interface comprising a display; and a processor, the processor programmed.
upon the electronic message icon being activated.
messages being “electronic.”
Additionally, claims 2-6, 8-12, and 14-21 includes further recitations of the above identified additional elements. The written description discloses that the recited computer components encompass generic components including “The device can be a computer or laptop with a web browser, a telephone with videoconferencing capability, a smart phone, a tablet, or other form of computing or mobile computing device” (see page 3, lines 9-11). As set forth in the MPEP 2106.04(d) “merely including instructions to implement an abstract idea on a computer” is an example of when an abstract idea has not been integrated into a practical application.
Claims 7-12, directly or indirectly, recite the following additional elements at a high level of generality, involving no more that extra-solution data gathering and transmitting activity:
Claim 7:
receiving input in the electronic medical records system via an interface.
receiving information via an interface.
These additional elements are recited at a high degree of generality and are merely involved in insignificant extra solution data gathering and transmitting of data over a generic computer network. As set forth in MPEP 2106.05(g) insignificant, extra-solution activity, such as insignificant acquisition and data transmission, is an example of when an abstract idea has not been integrated into a practical application.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to integration into a practical application, the additional elements are recited at a high level of generality, and the written description indicates that these elements are generic computer components. Using generic computer components to perform abstract ideas does not provide a necessary inventive concept. See Alice, 573 U.S. at 223 (“mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention.”).
Insignificant, extra solution, data gathering activity (e.g. transmitting and receiving data over a computer network) has been found to not amount to significantly more than an abstract idea (see MPEP 2106.05(g) and Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)).
Additionally, the aforementioned additional elements, considered in combination, do not provide an improvement to a technical field or provide a technical improvement to a technical problem. These additional elements merely carry out the abstract idea through data collection, data processing, data communication, and data storage. Therefore, whether considered alone or in combination, the additional elements do not amount to significantly more than the abstract idea.
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 6-7, and 12 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Koehl, US Patent No. 8,626,524 in view of Stoddard, US Patent No. 8,103,726.
As per claim 1, Stoddard teaches a computer system for initiating an electronic message in an electronic medical records system, the system comprising: a patient records database, the patient records database comprising patient charts corresponding to each of a plurality of patients (see column 5, lines 6-7; EHR system comprising patient charts); a user interface including a display (see column 4, lines 10-12; user interface comprising a display); and a processor in communication with the patient records database and the user interface (see column 7, lines 51-59; EHR system implemented with database and computer software communication architecture), the processor programmed to: receive commands to access a patient chart in the patient records database and provide access to the patient chart on the display (see column 8, lines 26-34; EHR system provides access to patient chart); present an electronic message icon on the display of the patient chart (see Figure 11; Compose Message is a selectable icon displayed on the display showing patient chart data); upon activation of the electronic message icon, display an electronic message template on the display, the electronic message template including a target field and a message field (see Figure 13; selection of Compose Message shows template with fields); receive one of the plurality of general event descriptors in the target field (see column 20, lines 23-29; general event descriptor could be message subject or content of the message); identify an electronic message format for an electronic message corresponding to the one of the plurality of general event descriptors, the message format defining a plurality of fields for contextual patient data in the message field (see column 20, lines 33-38; message composition screen identifies an electronic message format defining a plurality of fields, and the arrangement of fields corresponds to the general event descriptors because the provide fields for entry of such information); populate at least one of the plurality of fields for contextual data with patient data from the patient chart (see column 20, lines 30-32; at least one field may be populated with patient chart); and transmit the electronic message to the identified at least one recipient (see column 20, lines 39-49; column 21, lines 5-6; recipients of message are added and message is sent).
Koehl does not explicitly teach identify at least one recipient of the electronic message based on the general event descriptor. Stoddard teaches identify at least one recipient of an electronic message based on the general event descriptor (see column 7, lines 51-54; general even descriptor being a portion of the body of the message which is used to identify a context for an intended recipient; column 9, lines 44-50; based on the analysis of general event descriptor and context, a recipient address is identified). It would have been obvious to one of ordinary skill in the art at the time of the invention to identify a recipient for a message based on message context in the system of Koehl with the motivation of improving the user’s ability to have their messages sent to appropriate recipients (see column 2, lines 40-50 of Stoddard).
As per claim 6, Koehl and Stoddard teaches the system of claim 1 as described above. Koehl further teaches the processor is further programmed to provide a confirmation tool configured to receive input from the user input device to initiate the workflow (see column 21, lines 5-6; the send button initiates the workflow by sending the message).
As per claim 7, Koehl teaches a computer-implemented electronic messaging method for initiating at least one medical workflow for a patient in an electronic medical records system, the method comprising the steps of: providing a processor programmed (see column 7, lines 51-59; EHR system implemented with database and computer software communication architecture) to perform the steps of: receiving input identifying a patient in the electronic medical records system via an interface and presenting a patient chart on a display (see column 8, lines 26-34; HER system provides access to patient chart); providing an electronic message icon on the display (see Figure 11; Compose Message is a selectable icon displayed on the display showing patient chart data); upon activation of the electronic message icon, presenting an electronic message template on the display, wherein the electronic message template includes at least one target field configured to receive a general event descriptor and at least one message field (see Figure 13; selection of Compose Message shows template with fields); receiving the general event descriptor via an interface in the target message field and using the general event descriptor to identify an electronic message format identifying a plurality of fields for contextual data corresponding to the patient in a message field (see column 20, lines 23-29; general event descriptor could be message subject or content of the message; see column 20, lines 33-38; message composition screen identifies an electronic message format defining a plurality of fields, and the arrangement of fields corresponds to the general event descriptors because the provide fields for entry of such information); accessing the patient chart and populating at least one of the plurality of fields for contextual data with data from the chart (see column 20, lines 30-32; at least one field may be populated with patient chart); transmitting the electronic message to the at least one recipient and requesting the at least one recipient to begin a workflow corresponding to the general event descriptor (see column 20, lines 39-49; column 21, lines 5-6; recipients of message are added and message is sent).
Koehl does not explicitly teach using the general event descriptor to identify at least one recipient of the electronic message. Stoddard teaches using a general event descriptor to identify at least one recipient of an electronic message (see column 7, lines 51-54; general even descriptor being a portion of the body of the message which is used to identify a context for an intended recipient; column 9, lines 44-50; based on the analysis of general event descriptor and context, a recipient address is identified). It would have been obvious to one of ordinary skill in the art at the time of the invention to identify a recipient for a message based on message context in the system of Koehl with the motivation of improving the user’s ability to have their messages sent to appropriate recipients (see column 2, lines 40-50 of Stoddard).
As per claim 12, Koehl and Stoddard teaches the method of claim 7 as described above. Koehl further teaches associating patient contextual information with the electronic message includes adding a patient identifier to the electronic message (see column 20, lines 23-26 and Figure 15; patient identifying information associated with contextual information in the message).
Claim 2 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Koehl, US Patent No. 8,626,524 in view of Stoddard, US Patent No. 8,103,726 and further in view of Graves, US Patent Application Publication No. 2009/0147940.
As per claim 2, Koehl and Stoddard teaches the system of claim 1 as described above. Koehl and Stoddard does not explicitly teach a rules database correlating a plurality of general event descriptors with a corresponding plurality of electronic message formats. Graves teaches a rules database correlating a plurality of general event descriptors with a corresponding plurality of electronic message formats (see paragraphs 0099-0105; initiated electronic messages are formatted based on type of communication and recipient information). It would have been obvious to one of ordinary skill in the art at the time of the invention to add this formatting feature to the system of Koehl and Stoddard with the motivation of managing communication in a healthcare institution where a wide variety of formats may be utilized (see paragraph 0004 of Graves).
Claim 3-5 and 8-10 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Koehl, US Patent No. 8,626,524 in view of Stoddard, US Patent No. 8,103,726 and further in view of Napora, US Patent Application Publication No. 2009/0132586.
As per claim 3, Koehl and Stoddard teaches the system of claim 1 as described above. Koehl and Stoddard does not explicitly teach an entity capability database identifying a plurality of entities and corresponding capabilities. Napora teaches an entity capability database identifying a plurality of entities and corresponding capabilities (see paragraphs 0073 and 0096; user roles define capabilities of users related to medical workflows). It would have been obvious to one of ordinary skill in the art at the time of the invention to used the role-based workflow operations in the system of Koehl and Stoddard with the motivation of improving information exchange between entities with different roles in a healthcare setting (see paragraph 0006 of Napora).
As per claim 4, Koehl and Stoddard teaches the system of claim 3 as described above. Koehl and Stoddard does not explicitly teach the at least one recipient is an entity in the entity capability database. Napora further teaches the at least one recipient is an entity in the entity capability database (see paragraphs 0073 and 0096; user roles define capabilities of users related to medical workflows). It would have been obvious to one of ordinary skill in the art at the time of the invention to used the role-based workflow operations in the system of Koehl for the reasons given above with respect to claim 3.
As per claim 5, Koehl and Stoddard teaches the system of claim 3 as described above. Koehl further teaches the processor is further programmed to identify a workflow corresponding to the general event descriptor, and the electronic message requests the entity to start the medical workflow (see column 20, lines 24-29; reason for message identifies the type of workflow being requested).
As per claim 8, Koehl and Stoddard teaches the method of claim 7 as described above. Koehl and Stoddard does not explicitly teach providing an entity capability database, wherein identifying the recipient comprises identifying at least one entity from the entity capability database that is capable of providing the workflow identified by the general event descriptor in the target field. Napora teaches providing an entity capability database, wherein identifying the recipient comprises identifying at least one entity from the entity capability database that is capable of providing the workflow identified by the general event descriptor in the target field (see paragraphs 0073 and 0096; user roles define capabilities of users related to medical workflows). It would have been obvious to one of ordinary skill in the art at the time of the invention to use the role-based workflow operations in the system of Koehl and Stoddard with the motivation of improving information exchange between entities with different roles in a healthcare setting (see paragraph 0006 of Napora).
As per claim 9, Koehl, Stoddard, and Napora teaches the method of claim 8 as described above. Koehl and Stoddard does not explicitly teach transmitting the electronic message comprises transmitting the electronic message to the at least one entity that is identified to be capable of providing the workflow. Napora further teaches transmitting the electronic message comprises transmitting the electronic message to the at least one entity that is identified to be capable of providing the workflow (see paragraphs 0073 and 0096; user roles define capabilities of users related to medical workflows and forwards data to appropriate entity). It would have been obvious to one of ordinary skill in the art at the time of the invention to use the role-based workflow operations in the system of Koehl for the reasons given above with respect to claim 8.
As per claim 10, Koehl, Stoddard, and Napora teaches the method of claim 8 as described above. Koehl and Stoddard does not explicitly teach using the contextual information to identify the entity. Napora further teaches using the contextual information to identify the entity (see paragraph 0073; type of online form corresponds to the type of entity).
Claim 11 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Koehl, US Patent No. 8,626,524 in view of Stoddard, US Patent No. 8,103,726 and further in view of Wilkes, US Patent Application Publication No. 2011/0295961.
As per claim 11, Koehl and Stoddard teaches the method of claim 7 as described above. Koehl and Stoddard does not explicitly teach providing a rule set that correlates general event descriptors with contextual information types, and using the rule set to identify contextual information types correlated with the general event descriptor and identifying information corresponding to the identified contextual information type in the patient chart as patient contextual information. Wilkes teaches providing a rule set that correlates general event descriptors with contextual information types, and using the rule set to identify contextual information types correlated with the general event descriptor and identifying information corresponding to the identified contextual information type in the patient chart as patient contextual information (see paragraph 0055; determines context from descriptive information within a data message, and determines the context to correspond to patient chart). It would have been obvious to one of ordinary skill in the art at time of the invention to add these features to the system of Koehl and Stoddard with the motivation of providing more convenient delivery of relevant patient information (see paragraph 0004 of Wilkes).
Claim 13-21 is/are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Koehl, US Patent No. 8,626,524 in view of Napora, US Patent Application Publication No. 2009/0132586
As per claim 13, Koehl teaches a computer-implemented electronic messaging system, the system comprising: a database comprising a plurality of patient charts, each patient chart including patient medical records for an associated patient, the patient medical records including pre-defined fields (see column 5, lines 6-7; EHR system comprising patient charts); a user interface comprising a display (see column 4, lines 10-12; user interface comprising a display); and a processor, the processor programmed to: receive a command to access a patient chart ((see column 8, lines 26-34; EHR system provides access to patient chart); present the patient chart on the display (see column 8, lines 26-34; EHR system provides access to patient chart); present an electronic message icon on the display (see Figure 11; Compose Message is a selectable icon displayed on the display showing patient chart data); upon the electronic message icon being activated, present an electronic message template on the display, the electronic message template including a target field and a message field (see Figure 13; selection of Compose Message shows template with fields); receive a general event descriptor in the target field and utilize the general event descriptor to format a message entered into the message field, the message comprising a plurality of contextual data fields for receiving contextual data corresponding to the patient chart (see column 20, lines 23-29; general event descriptor could be message subject or content of the message; see column 20, lines 33-38; message composition screen identifies an electronic message format defining a plurality of fields, and the arrangement of fields corresponds to the general event descriptors because the provide fields for entry of such information); retrieve data from the patient chart to populate the contextual data fields (see column 20, lines 30-32; at least one field may be populated with patient chart); and transmit the electronic message to the identified recipient (see column 20, lines 39-49; column 21, lines 5-6; recipients of message are added and message is sent).
Koehl does not explicitly teach identify a workflow to be performed based on at least one of the general event descriptor and the contextual data in the contextual data fields; identify a recipient based on the identified workflow. Napora teaches identify a workflow to be performed based on at least one of a general event descriptor and the contextual data in contextual data fields (see paragraph 0061; message broker identifies data for forwarding during a medical workflow); identify a recipient based on the identified workflow (see paragraph 0072-0073; type of recipient for a particular workflow is identified). It would have been obvious to one of ordinary skill in the art at the time of the invention to use the role-based workflow operations in the system of Koehl with the motivation of improving information exchange between entities with different roles in a healthcare setting (see paragraph 0006 of Napora).
As per claim 14, Koehl and Napora teaches the system of claim 13 as described above. Koehl does not explicitly teach the processor is further programmed to access a rules database to identify the workflow. Napora further teaches the processor is further programmed to access a rules database to identify the workflow (see paragraph 0051; rules are applied to data elements during a medical workflow). It would have been obvious to one of ordinary skill in the art at the time of the invention to use the role-based workflow operations in the system of Koehl for the reasons given above with respect to claim 13.
As per claim 15, Koehl and Napora teaches the system of claim 13 as described above. Koehl does not explicitly teach the processor is further programmed to access an entity capability database and use the general event descriptor to identify the recipient as at least one entity capable of providing the identified workflow corresponding to the general event descriptor. Napora further teaches he processor is further programmed to access an entity capability database and use the general event descriptor to identify the recipient as at least one entity capable of providing the identified workflow corresponding to the general event descriptor (see paragraphs 0073 and 0096; user roles define capabilities of users related to medical workflows). It would have been obvious to one of ordinary skill in the art at the time of the invention to use the role-based workflow operations in the system of Koehl for the reasons given above with respect to claim 13.
As per claim 16, Koehl and Napora teaches the system of claim 13 as described above. Koehl further teaches the general event descriptor identifies at least one of a test/procedure, a referral/consult, or a follow-up patient care (see Figure 15; shows test in a panel of the message and patient referral in a different field).
As per claim 17, Koehl and Napora teaches the system of claim 16 as described above. Koehl further teaches the contextual data comprises one or more of a patient identifier, a patient address, a patient age, and a patient gender (see column 12, line 2; patient age, gender, ID).
As per claim 18, Koehl and Napora teaches the system of claim 16 as described above. Koehl further teaches the processor is further programmed to generate a warning window and present a field for contextual data that is not found in the patient chart (see Figure 13; shows windows for accepting information, which may or may not be from the patient chart).
As per claim 19, Koehl and Napora teaches the system of claim 16 as described above. Koehl further teaches the processor is further programmed to add at least one of a patient name and a patient identifier to the target field (see column 12, line 2; patient age, gender, ID; Figures 13 and 16; shows patient name added).
As per claim 20, Koehl and Napora teaches the system of claim 16 as described above. Koehl further teaches the processor is further programmed to identify a geographically optimal entity (see column 18, lines 46-52; identifies entities based on location).
As per claim 21, Koehl and Napora teaches the system of claim 16 as described above. Koehl further teaches the processor is further programmed to highlight contextual data from the patient chart (see Figure 15; shows patient chart data highlighted as attachments).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Davis, US Patent Application Publication No. 2003/0028399, discloses auto-filling fields in a clinician e-mail.
Geertsen, US Patent Application Publication No. 2004/0039596, discloses automatically generating clinical messages based on message templates.
Krishnamurthi, US Patent 2010/0161743, discloses routing and re-routing messages based on recipient availability.
Verkerk, US Patent Application Publication No. 2019/0057771, discloses identifying message templates from patient records.
Brown, International Publication No. WO 00/11578, discloses a platform to assist clinicians in composing electronic messages.
Mori et al., Integration of Clinical Information Across Patient Records: A Comparison of Mechanisms Used to Enforce Semantic Coherence, discloses communicating clinical messages with segmented data fields across independent systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to C. Luke Gilligan whose telephone number is (571)272-6770. The examiner can normally be reached Monday through Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Robert Morgan can be reached at 571-272-6773. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHRISTOPHER L GILLIGAN/ Primary Examiner, Art Unit 3683
Prosecution Insights