Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of claims
This non-final office action on merits is in response to the Patent Application filed on 1/17/2025. Claims 2-20 are new. Amendments to claim 1 is acknowledged and have been carefully considered. Claims 1-20 are pending and considered below. This application is a Continuation of application 18/410253, filed on 01/11/2024, which is Continuation of application 17/443550, filed on 07/27/2021, which is a Continuation of application 16/585457, filed on 09/27/2019, which is a Continuation-in-part of application 15/437857, filed on 02/21/2017, which claims the benefit of Provisional Application No. 62/439,543, filed on 12/28/2016.
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, 8, and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 9, and 14 of U.S. Patent No. 10453565 B2 (’565 patent).
Claim 1 is rejected because the ’565 patent teaches a computer-implemented system and method for transmitting messages containing clinically relevant information derived from electronic medical records to a destination within a separate domain without requiring knowledge of a target endpoint address. Specifically, the ’565 patent discloses detecting a request to transmit a message including clinically relevant information identified from one or more electronic medical records to a destination within a separate domain, determining whether the destination is associated with a role, identifying an intended target associated with the role, generating a transmission for the intended target without the endpoint address, and electronically communicating the transmission to the intended target (see claims 1 and 9 of the ’565 patent).
Similarly, the present claim 1 recites accessing electronic medical records, generating a payload containing clinically relevant information derived from the electronic medical records, and sending a request to transmit a message containing the payload to a destination associated with a target device, wherein the control server and the destination are in separate domains associated with a medical environment. These limitations correspond to the messaging functionality disclosed in the ’565 patent in which clinically relevant information from electronic medical records is transmitted across domains to a destination within another domain.
The additional limitations of claim 1 directed to determining whether a first path for transmitting the message to the target endpoint address is unavailable and receiving a notification corresponding to message routing information represent routine message delivery management and routing operations that would have been obvious to incorporate into the messaging system of the ’565 patent in order to improve delivery reliability and provide feedback regarding message transmission status. Such routing and notification functionality constitutes a predictable implementation of known messaging system features and does not render the claimed invention patentably distinct from the subject matter claimed in the ’565 patent.
Claims 8 and 15 are rejected under the doctrine of nonstatutory obviousness-type double patenting for the same reasons set forth with respect to claim 1. Claims 8 and 15 recite substantially the same limitations as claim 1 but are presented in different statutory classes, as a computer-readable medium and a system, respectively. Specifically, claims 8 and 15 similarly recite accessing electronic medical records, generating a payload containing clinically relevant information derived from the electronic medical records, transmitting a request to send the message to a destination associated with a target device across separate domains within a medical environment, determining whether a transmission path to the target endpoint address is unavailable, and receiving a notification regarding message routing information. These limitations correspond to the messaging functionality disclosed in claims 1 and 9 of the ’565 patent and differ only in the recitation of the invention in a different statutory form. Accordingly, claims 8 and 15 are not patentably distinct from the subject matter claimed in the ’565 patent for the reasons discussed above.
Claim Rejections - 35 USC § 112
Claims 5-6 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Specifically, claim 5 recites that “the push receipt is configured to indicate to the source device information corresponding to the first path being unavailable.” Similarly, claim 6 recites that “the notification further comprises an indication that the second path to the target endpoint address has been identified as available for transmitting the message to the target endpoint address.” However, the specification does not disclose a push receipt or notification that indicates that a first transmission path is unavailable or that a second path has been identified as available.
The specification only discloses that when an optimal path is not available, the system identifies an alternate path and communicates a notification of the message via the alternate path. The specification further states that a push receipt may optionally be communicated from the manager to the source device to notify the source device that an alternate path was used (see paragraph [0044]). The specification therefore describes notifying the source device that an alternate path was used, but does not describe a push receipt indicating that a first path is unavailable or that a second path has been identified as available for transmitting the message, as recited in claims 5 and 6.
Accordingly, the specification fails to reasonably convey to one of ordinary skill in the art that the inventor had possession of the subject matter of claims 5 and 6 at the time of filing.
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 an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1-7 are drawn to a computer-implemented method, claims 8-14 are drawn to one or more non-transitory media, and claims 15-20 are drawn to a system. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 1 recites as a whole a method of organizing human activity (i.e., commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); or managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions)) because the claim recites a method that allows users to retrieve clinical information from electronic records, generate the message including the clinical information, and transmit the message to a destination associated with another user or device in a medical environment, while receiving a notification regarding the routing of the message. This is a method of managing interactions and communications between individuals in a medical environment regarding clinical information. The mere nominal recitation of a generic at least one hardware processor associated with a source device and a control server does not take the claim out of certain methods of organizing human activity. Thus, the claim recites an abstract idea.
Claim 1 also recites the limitation of to determine whether a first path for transmitting the message to a target endpoint address associated with the target device is unavailable. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind or by using a pen and paper. But for the “the control server is configured to” language, the claim encompasses a user evaluating whether a communication path to the intended recipient is available and deciding that the path is unavailable before attempting an alternative route in their mind or by using a pen and paper. The mere nominal recitation of the control server does not take the claim limitation out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
The types of identified abstract ideas are considered together as a single abstract idea for analysis purposes.
Independent claim 8 and 15 recites identical or nearly identical steps with respect to claim 1 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per method claim 1, include the steps of:
accessing, via at least one hardware processor associated with a source device that is configured to communicate at a medical environment that includes a control server, one or more electronic medical records that are stored at or associated with a database in the medical environment;
generating, via the at least one hardware processor, a payload for use with a message to be communicated via the control server;
sending, via the at least one hardware processor, a request to transmit the message to a destination associated with a target device, the message including the payload and comprising particular clinical information identified from one or more electronic medical records,
wherein: the control server and the destination are in separate domains associated with the medical environment; and the control server is configured to determine whether a first path for transmitting the message to a target endpoint address associated with the target device is unavailable; and
receiving, via one or both of the at least one hardware processor and the source device and in response to the sending of the request to transmit, a notification corresponding to content selected from a group comprising at least the message, the target endpoint address, and a second path for transmitting the message to the target endpoint address associated with the target device.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of communicating clinical information between parties and determining routing availability for these communications in a computer environment. The claimed computer components (i.e., via at least one hardware processor associated with a source device; that includes a control server; via the at least one hardware processor; via the control server; and the control server is configured to; and via one or both of the at least one hardware processor and the source device) are recited at a high level of generality and are merely invoked as tools to perform an existing process of retrieving information, generating a message containing information, transmitting the message to a destination, determining whether the communication path is available, and notifying the sender regarding routing information. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 1 is not integrated into a practical application. The abstract idea is merely carried out in a technical environment or field (i.e., a medical or clinical communication environment), however fails to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (see MPEP 2106.05(h)). The additional elements that are carried out in a technical environment includes to communicate at a medical environment; associated with a database in the medical environment; and wherein: the control server and the destination are in separate domains associated with the medical environment. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim recites the additional element of accessing one or more electronic medical records that are stored at or associated with a database. This limitation is recited at a high level of generality (i.e., as a general means of receiving or obtaining information for use of generating and transmitting a message), and amounts to merely mere data gathering, which is a form of insignificant extra-solution activity. Accordingly, even in combination, this additional element does not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of communicating clinical information between parties and determining routing availability for these communications in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the abstract idea is merely carried out in a technical environment or field, however fails to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
For claim 1, under step 2B, the additional element of accessing one or more electronic medical records that are stored at or associated with a database has been evaluated. The method comprising via at least one hardware processor associated with a source device performs a general function of receiving patient data for inclusion in a message containing clinical information, which represents a well-understood, routine, and conventional activity in the field of electronical medical record systems and healthcare information management. The specification discloses that the processor is used in its ordinary capacity as a data input device and does not describe any improvement to the computer itself or to the functioning of the overall computer system (see page 4 and 5). Also noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for communication or analysis without a technological improvement does not add significantly more to an abstract idea. The use of the method is no more than collecting information before performing organizing and transmitting clinical communication between parties and does not integrate the abstract idea into a practical application. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 2-3, 5-6, 9-10, 12-13, 16, and 18-19 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claims 4, 7, 11, 14, 17, and 20 recite the additional elements of from the control server (claims 4, 11, and 17), by the control server (claims 7, 14, and 20). However, these additional elements amount to implementing an abstract idea on a generic computing device. As such, these additional elements, when considered individually or in combination with the prior devices, do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claim is rejected under 35 U.S.C. 101 for lacking eligible 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 (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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rybkin (U.S. Patent Publication 2016/0004836 A1), referred to hereinafter as Rybkin, in view of Kim et al. (U.S. Patent No. 9467970 B1), referred to hereinafter as Kim, and Underwood et al. (U.S. Patent Publication 2010/0325470A1), referred to hereinafter as Underwood.
Regarding claim 1, Rybkin teaches a computer-implemented method (Rybkin [0004] “The method may be implemented by a computer system including computer hardware.”), comprising:
accessing, via at least one hardware processor associated with a source device that is configured to communicate at a medical environment that includes a control server, one or more electronic medical records that are stored at or associated with a database in the medical environment (Rybkin [0006] “In several embodiments, non-transitory physical computer storage can include instructions stored thereon that, when executed by one or more processors, cause the one or more processors to implement a system for making patient care messages available to healthcare providers on different shifts.”, Rybkin [0041] “In an embodiment, when the patient first presents to or visits with the provider (or earlier), the provider associates the patient with his team using a patient user interface 550, as shown in FIG. 5B. The user interface 550 lists (or has the facility 572 or 574 to search and dynamically list) some or all available patient records 560 stored by the aggregator 120. The provider may generate a new patient record if the patient is new to the aggregator 120. Alternatively the list of patient and patient records may be imported from the Electronic Medical Record database 130 (for example using an HL7 ADT data feed). The list of patients 560 allows the provider import the patient to one of provider's teams. For example, in the depicted embodiment, a link 564 is provided for importing a particular patient to a team. This link can be provided for any patient not currently affiliated with a team. Other patients that are already on a team are shown with their team affiliation (e.g., “Medicine 1A”). A drop-down box 562 enables a user to select a particular team for a given patient not yet assigned to a team. In some cases, the user interface 550 may also be used to change a patient's team affiliation (see also FIG. 6A).”, and Rybkin [0090] “In several embodiments, the aggregator 120 functions as an add-on component of the EHR (Electronic Health Record) system or EMR system, supplementing current functionality with enhanced messaging and dynamic routing capabilities. Although this implementation is made seamless in some embodiments with the EHR from the workflow standpoint by the use of single sign-on technologies and integration interfaces, the aggregator 120 can still be a stand-alone system. In another embodiment, the aggregator 120 can perform the totality of the functions of the EHR, thereby wrapping the medical data in the messaging functionality, and user-defined dynamic actions. In this embodiment, the concepts of dynamic determination of the provider in charge of the patient, dynamic conditional routing of messages and the resulting electronic dialogue can be used as guiding principle in constructing the EHR's of the future. Wrapping medical data (including, for example, medications, problems, etc) into messaging functionality with dynamic logic (e.g., actions) can therefore be an advantageous paradigmatic shift from the current static representation of data in the Electronic Health or Medical Records (EHR/EMR).”);
generating, via the at least one hardware processor, a payload for use with a message to be communicated via the control server (Rybkin [0006] “In several embodiments, non-transitory physical computer storage can include instructions stored thereon that, when executed by one or more processors, cause the one or more processors to implement a system for making patient care messages available to healthcare providers on different shifts. The system can include: a messaging component that can: electronically generate a patient messaging user interface; provide a first team of healthcare providers with access to the patient messaging user interface while the first team of healthcare providers is assigned to care for the patient, where the patient messaging user interface can enable the first team of healthcare providers to post messages regarding care of the patient for access by each member of the first team of healthcare providers and by the second team of healthcare providers, without the first team of healthcare providers having to know an identity of the second team of healthcare providers when posting the messages; and automatically provide the second team of healthcare providers with access to the posted message regarding the patient posted by the first team of healthcare providers in response to care of the patient being transferred from the first team of healthcare providers to the second team of healthcare providers.”, Rybkin [0019] “Users of the aggregator 120 can include any provider or clinician, any hospital or clinical facility staff member (including clerical staff), and the like. In one embodiment, providers or other users connect to the aggregator 120 through a LAN, WAN, or other network (including optionally the Internet or wireless networks), using any client device. Some examples of client devices include computers or mobile devices 102, such as smart phones, laptops, touch pads, kiosks, desktops, and the like. Users can also access the aggregator 120 through an EMR application 104 and optionally using browser software 106 or other client software installed on a client device.” Rybkin [0020] “The aggregator 120 can include software that executes on one or more computing devices, such as one or more physical server computers. In embodiments where the aggregator 120 is implemented on multiple servers, these servers can be co-located or can be geographically separate (such as in separate data centers). In addition, the aggregator 120 can be implemented in a cloud computing platform, such as may be available from Amazon Web Services™, the Windows Azure™ Platform, or the like. For instance, the aggregator 120 can be implemented in one or more virtual machines that execute on one or more physical servers. Further, the aggregator 120 can include a server or appliance on the local area network, which is protected from the wide area network (e.g., the public Internet or other network) by a firewall or other security mechanism.”);
sending, via the at least one hardware processor, a request to transmit the message to a destination associated with a target device, the message including the payload and comprising particular clinical information identified from one or more electronic medical records (Rybkin [0031] Referring to FIG. 3B, an embodiment of a process 350 is shown for routing messages to the appropriate provider without having to know the identity of that provider beforehand. The process 350 can be performed by the aggregator 120, and more particularly, by the messaging component 124, Rybkin [0033] “At block 356, the messaging component 124 determines a team associated with the patient by consulting a patient-team association table 355 or the like. Once the team is identified, the messaging component 124 can determine which doctors are associated with that team at block 357 by accessing a doctor-team association table 358 or the like. The messaging component 124 then determines whether a given one of those doctors is currently on duty at decision block 360. (The process of picking a particular doctor to contact from a team of doctors is described in greater detail below.) The messaging component 124 can determine this doctor status information by consulting the status monitor database 359. If the relevant doctor from the team is currently on duty, the messaging component 124 delivers the message to the doctor at block 362. The message can be delivered via pager 364, secure (or other) mobile communications 366, via a doctor dashboard 368 or similar display (see below), or the like. If the doctor is not available, the messaging component 124 can determine whether another doctor in the team is available, repeating blocks 360 through 362.”, and Rybkin [0019] “Users of the aggregator 120 can include any provider or clinician, any hospital or clinical facility staff member (including clerical staff), and the like. In one embodiment, providers or other users connect to the aggregator 120 through a LAN, WAN, or other network (including optionally the Internet or wireless networks), using any client device. Some examples of client devices include computers or mobile devices 102, such as smart phones, laptops, touch pads, kiosks, desktops, and the like. Users can also access the aggregator 120 through an EMR application 104 and optionally using browser software 106 or other client software installed on a client device.”),
wherein: the control server and the destination are in separate domains associated with the medical environment (Rybkin [0080] “So far a system of messaging within a local area network has been discussed. Such a system communicates with the outside Wide Area Network (WAN) through the institution's firewall, in order to access the common facilities for paging and messaging. A possible embodiment of the aggregator 120 may have secure connections across the WAN with facilities for common servicing and maintenance of the aggregator 120. Connections could also exist among such systems at different healthcare institutions, allowing free secure communication among providers in multiple settings, including outpatient settings, doctor's office settings, nursing homes, and home care settings, among others. Moreover, some or all the functions of the aggregator 120, such as data storage and messaging, could be centralized in a scalable “cloud” infrastructure, leveraging efficiencies of scale and minimizing cost for healthcare providers and institutions. Extending this concept further, a super aggregator could be established in a cloud computing platform or in one or more data centers, which would enable collaboration of patient information, handoffs, and messaging among multiple clinical facilities, including hospitals, doctors' offices, pharmacies, labs, in-home healthcare, and the like.”);
Rybkin fails to explicitly teach the control server is configured to determine whether a first path for transmitting the message to a target endpoint address associated with the target device is unavailable; and receiving, via one or both of the at least one hardware processor and the source device and in response to the sending of the request to transmit, a notification corresponding to content selected from a group comprising at least the message, the target endpoint address, and a second path for transmitting the message to the target endpoint address associated with the target device.
Kim teaches the control server is configured to determine whether a first path for transmitting the message to a target endpoint address associated with the target device is unavailable (Kim, Col. 29, lines 18-30, “At block 712, in at least one of the various embodiments, the available message providers associated with the determined region may be determined. In at least one of the various embodiments, the notification engine may retrieve a list/collection of message providers that are associated with a particular region from a database or other data store. In some cases, there may be message providers that may be associated with a region but for some reason are determined to be unavailable. As discussed in more detail below, in at least one of the various embodiments, a message provider may be determined to be unavailable for a variety of reasons, including, being offline, too costly, too unreliable, or the like, or combination thereof.”); and
a second path for transmitting the message to the target endpoint address associated with the target device (Kim, Col. 22, lines 7-19, “In at least one of the various embodiments, multiple message providers may be associated with a region to identify fallback providers that may be used if the preferred message provider is unavailable (e.g., due to a system failure, or the like). Also, rather than exclusively routing notification message using the most preferred provider, message providers may be allocated a notification message based on a proportional distribution corresponding to their weighting values. For example, according to table 512, for region 506 message providers “X3” and “X4” are the least preferred providers. However, in this example, 10% of notifications may be delivered using provider “X3” and 10% may be delivered using provider “X4.”).
Underwood teaches receiving, via one or both of the at least one hardware processor and the source device and in response to the sending of the request to transmit, a notification corresponding to content selected from a group comprising at least the message, the target endpoint address (Underwood [0048] “As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the messaging system of Rybkin to further include determining whether a transmission path is unavailable and providing notification information regarding the message transmission as taught by Kim and Underwood. Rybkin teaches a computer implemented healthcare messaging system that accesses patient information from electronic medical records and generates and transmits messages containing clinical information to healthcare providers through networked computing systems. Rybkin further teaches that such messaging systems may operate across multiple healthcare institutions connected via wide area networks, thereby supporting communication between systems located in separate domains associated with a medical environment. However, Rybkin does not explicitly disclose determining whether a first transmission path is unavailable before delivering the message or providing notification information regarding message delivery paths.
Kim teaches determining whether message providers associated with a region are unavailable and selecting alternate providers when a preferred provider is unavailable. Underwood teaches that when a message is transmitted through a delivery server, an acknowledgement or notification is returned to the originating device, and when a primary delivery channel is unavailable the system routes the message through an alternate delivery channel such as email or SMS. One of ordinary skill in the art would have found it obvious to incorporate the availability determination and fallback routing mechanisms of Kim and the acknowledgement and alternate delivery notification mechanisms of Underwood into the messaging system of Rybkin in order to improve the reliability of message delivery in networked healthcare communication systems. Applying these known techniques to Rybkin’s messaging infrastructure would have predictably allowed the system to detect unavailable message transmission paths, select alternate routing providers, and notify the originating device regarding message delivery status or alternate routing paths, thereby ensuring more reliable delivery of clinical communications across distributed healthcare networks.
Combining these known techniques would merely involve applying well-known message routing, acknowledgement, and fallback communication mechanisms to an existing healthcare messaging platform, which would have been a predictable use of prior art elements according to their established functions. Therefore, the combination of Rybkin in view of Kim and Underwood would have rendered the claimed invention obvious to a person having ordinary skill in the art.
Regarding claim 2, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein sending the request to transmit includes addressing the request to transmit to the control server (Rybkin [0031] Referring to FIG. 3B, an embodiment of a process 350 is shown for routing messages to the appropriate provider without having to know the identity of that provider beforehand. The process 350 can be performed by the aggregator 120, and more particularly, by the messaging component 124, Rybkin [0033] “At block 356, the messaging component 124 determines a team associated with the patient by consulting a patient-team association table 355 or the like. Once the team is identified, the messaging component 124 can determine which doctors are associated with that team at block 357 by accessing a doctor-team association table 358 or the like. The messaging component 124 then determines whether a given one of those doctors is currently on duty at decision block 360. (The process of picking a particular doctor to contact from a team of doctors is described in greater detail below.) The messaging component 124 can determine this doctor status information by consulting the status monitor database 359. If the relevant doctor from the team is currently on duty, the messaging component 124 delivers the message to the doctor at block 362. The message can be delivered via pager 364, secure (or other) mobile communications 366, via a doctor dashboard 368 or similar display (see below), or the like. If the doctor is not available, the messaging component 124 can determine whether another doctor in the team is available, repeating blocks 360 through 362.”, Rybkin [0019] “Users of the aggregator 120 can include any provider or clinician, any hospital or clinical facility staff member (including clerical staff), and the like. In one embodiment, providers or other users connect to the aggregator 120 through a LAN, WAN, or other network (including optionally the Internet or wireless networks), using any client device. Some examples of client devices include computers or mobile devices 102, such as smart phones, laptops, touch pads, kiosks, desktops, and the like. Users can also access the aggregator 120 through an EMR application 104 and optionally using browser software 106 or other client software installed on a client device.”, and Rybkin [0006] “In several embodiments, non-transitory physical computer storage can include instructions stored thereon that, when executed by one or more processors, cause the one or more processors to implement a system for making patient care messages available to healthcare providers on different shifts.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the messaging system such that the request to transmit the message is addressed to a control server as taught by Rybkin. Rybkin discloses a messaging system in which healthcare providers post messages regarding patient care to a messaging component of an aggregator system, which then distributes the messages to appropriate providers. Rybkin further teaches that client devices connect to the aggregator system through a network and that the messaging component receives and routes messages to appropriate provider devices. One of ordinary skill in the art would have recognized that sending the transmission request to the server component of such a system is a conventional client/server messaging architecture that enables centralized message routing and management. Implementing this architecture would have been a predictable use of prior art elements according to their established functions to facilitate routing messages to appropriate recipients in the medical messaging system.
Regarding claim 3, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein the notification comprises a push receipt (Underwood [0048] ”As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”, Underwood [0049] “Where email is the selected alternate delivery route, the delivery server 105 converts the message from its native format to the appropriate email format before forwarding the message 205 to the email gateway. Email gateway 108 then forwards the message 207 to the recipient device 107, the recipient device then sends back an acknowledgement message 208.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the notification in the messaging system to include a push receipt as taught by Underwood. Underwood teaches that when a message is transmitted through a delivery server, the server sends an acknowledgement message back to the originating device and optionally advises the sending device of successful end-to-end delivery of the message. Providing such acknowledgement notifications confirms successful message transmission and delivery to the sender. One of ordinary skill in the art would have been motivated to incorporate this acknowledgement or push receipt functionality into the messaging system to provide confirmation of message delivery and improve reliability and usability of the messaging system. Implementing this known acknowledgement mechanism in the messaging environment would have been a predictable use of prior art elements according to their established functions.
Regarding claim 4, Rybkin, Kim, and Underwood teach the invention in claim 3, as discussed above, and further teach wherein the push receipt is received at the source device from the control server (Underwood [0048] ”As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”, Underwood [0049] “Where email is the selected alternate delivery route, the delivery server 105 converts the message from its native format to the appropriate email format before forwarding the message 205 to the email gateway. Email gateway 108 then forwards the message 207 to the recipient device 107, the recipient device then sends back an acknowledgement message 208.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the messaging system such that the push receipt is received at the source device from the control server as taught by Underwood. Underwood teaches that after an originating device forwards a message to a delivery server, the delivery server sends an acknowledgement message back to the originating device confirming transmission or delivery of the message. Providing such server generated acknowledgement notifications to the originating device would have been an obvious choice to inform the sender of message transmission status and improve reliability of the messaging system, representing the predictable use of known messaging acknowledgement techniques according to their established functions.
Regarding claim 5, Rybkin, Kim, and Underwood teach the invention in claim 4, as discussed above, and further teach wherein the push receipt is configured to indicate to the source device information corresponding to the first path being unavailable (Underwood [0048] ”As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”, Underwood [0049] “Where email is the selected alternate delivery route, the delivery server 105 converts the message from its native format to the appropriate email format before forwarding the message 205 to the email gateway. Email gateway 108 then forwards the message 207 to the recipient device 107, the recipient device then sends back an acknowledgement message 208.” and
Kim, Col. 29, lines 18-30, “At block 712, in at least one of the various embodiments, the available message providers associated with the determined region may be determined. In at least one of the various embodiments, the notification engine may retrieve a list/collection of message providers that are associated with a particular region from a database or other data store. In some cases, there may be message providers that may be associated with a region but for some reason are determined to be unavailable. As discussed in more detail below, in at least one of the various embodiments, a message provider may be determined to be unavailable for a variety of reasons, including, being offline, too costly, too unreliable, or the like, or combination thereof.”).
It would have been obvious to one of ordinary skill in the art to configure the notification system of Underwood to indicate that a primary transmission path is unavailable as taught by Kim. Kim teaches determining when message providers are unavailable, while Underwood teaches sending acknowledgements and routing messages through alternate delivery channels when the primary channel is unavailable. Combining these known techniques would have predictably allowed the system to notify the originating device that the primary transmission path was unavailable and that alternate routing was used, thereby improving reliability of message delivery.
Regarding claim 6, Rybkin, Kim, and Underwood teach the invention in claim 3, as discussed above, and further teach wherein the notification further comprises an indication that the second path to the target endpoint address has been identified as available for transmitting the message to the target endpoint address (Underwood [0048] “As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”). and
Kim, Col. 22, lines 7-19, “In at least one of the various embodiments, multiple message providers may be associated with a region to identify fallback providers that may be used if the preferred message provider is unavailable (e.g., due to a system failure, or the like). Also, rather than exclusively routing notification message using the most preferred provider, message providers may be allocated a notification message based on a proportional distribution corresponding to their weighting values. For example, according to table 512, for region 506 message providers “X3” and “X4” are the least preferred providers. However, in this example, 10% of notifications may be delivered using provider “X3” and 10% may be delivered using provider “X4.”).
It would have been obvious to one of ordinary skill in the art to configure the messaging notification system of Underwood to indicate that an alternate transmission path has been identified as available as taught by Kim. Kim teaches identifying fallback message providers that can be used when a preferred provider is unavailable, while Underwood teaches routing messages through alternate delivery channels when the primary channel fails. Combining these teachings would have predictably enabled the system to notify the sender that an alternate delivery path has been identified and is available for message transmission, thereby improving message delivery reliability.
Regarding claim 7, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein receiving the notification corresponds to determining delivery information with respect to the target endpoint address or with respect to use of the second path by the control server in connection with responding to the request to transmit (Underwood [0048] “As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”). and
Kim, Col. 22, lines 7-19, “In at least one of the various embodiments, multiple message providers may be associated with a region to identify fallback providers that may be used if the preferred message provider is unavailable (e.g., due to a system failure, or the like). Also, rather than exclusively routing notification message using the most preferred provider, message providers may be allocated a notification message based on a proportional distribution corresponding to their weighting values. For example, according to table 512, for region 506 message providers “X3” and “X4” are the least preferred providers. However, in this example, 10% of notifications may be delivered using provider “X3” and 10% may be delivered using provider “X4.”).
It would have been obvious to one of ordinary skill in the art to configure the messaging system of Underwood to provide delivery information or alternate routing information in response to message transmission as taught by Kim. Underwood teaches sending acknowledgements and delivery confirmations to the originating device, while Kim teaches identifying alternate message providers when a preferred provider is unavailable. Combining these teachings would have predictably allowed the system to provide notification information regarding message delivery status or the use of alternate routing paths.
Claims 8-14 are analogous to claims 1-7, thus claims 8-14 are similarly analyzed and rejected in a manner consistent with the rejection of claims 1-7.
Claim 15 is analogous to claim 1, thus claim 15 is similarly analyzed and rejected in a manner consistent with the rejection of claim 1.
Claim 16 is analogous to claim 2, thus claim 16 is similarly analyzed and rejected in a manner consistent with the rejection of claim 2.
Claim 17 is analogous to claims 3 and 4, thus claim 17 is similarly analyzed and rejected in a manner consistent with the rejection of claims 3 and 4.
Claims 18-20 are analogous to claims 5-7, thus claims 18-20 are similarly analyzed and rejected in a manner consistent with the rejection of claims 5-7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Vesto et al. (U.S. Publication No. 2016/0063191 A1) teaches a healthcare integration platform that uses reusable interface definitions, machine learning analysis of messaging traffic, and graph based connection metadata to predict communication needs and automatically suggest provision data exchange between source and target systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kambiz Abdi can be reached at (571)272-6702. 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.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685