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 of the present application recites detecting a request to transmit a message to a destination, determining that a first path for transmitting the message is unavailable, identifying a second path, and generating a notification to the source device indicating content or delivery information associated with the message.
Claim 9 of the ’565 patent recites detecting a request to transmit a message, generating a first transmission to an intended target, detecting a change to information associated with the message, and generating and communicating an updated transmission associated with the first transmission.
The ’565 patent teaches the same automated follow-up communication based on a condition associated with a prior transmission as claim 1 of the present application, including generating a subsequent communication that conveys information relating to an earlier message transmission. Claim 1 of the present application differs in that the triggering condition is unavailability of a delivery path rather than a change in clinically relevant information. However, the ’565 patent teaches generating a second communication in response to a detected condition affecting the prior message and communicating information regarding that message. It would have been obvious to one of ordinary skill in the art to generate such a follow-up communication when other message-related conditions occur, including delivery failure, as this represents a predictable use of the same messaging mechanism to convey status information about a prior transmission. Accordingly, claim 1 is an obvious variation of claim 9 of the ’565 patent.
Claim 8 of the present application recites non-transitory media storing instructions that cause processors to detect a request to transmit a message, determine that a first transmission path is unavailable, identify a second path, and push a request receipt element to the source device indicating message content or delivery information associated with the message.
Claim 14 of the ’565 application recites non-transitory media storing instructions that cause a computing device to detect a request to transmit a message without an endpoint address, identify intended targets, transmit the message, and communicate device and read acknowledgements and responses associated with the transmission to the source device.
The ’565 application teaches the same automated communication of information describing the status of a message transmission as claim 8 of the present application, including generating and sending follow-up communications to the source device conveying delivery-related information associated with a prior transmission. Claim 8 of the present application differs in that the follow-up communication is triggered by unavailability of a transmission path and reports alternate-path delivery information rather than acknowledgements or responses after successful delivery. However, the ’565 application teaches communicating transmission-status information regarding a previously generated message back to the source device. It would have been obvious to one of ordinary skill in the art to provide such transmission-status communication in response to other message-related conditions, including delivery failure and alternate routing, as this represents a predictable variation of the same messaging status reporting mechanism. Accordingly, claim 8 is an obvious variation of claim 14 of the ’565 application.
Claim 15 of the present application recites a system configured to detect a request to transmit a message, determine that a first transmission path to a target endpoint is unavailable, identify a second path, and push a request receipt element to the source device indicating message content or delivery information associated with the message.
Claim 1 of the ’565 application recites a system configured to detect a request to transmit a message, identify an intended target, generate and transmit a first transmission, detect a change associated with the message, and generate and communicate an updated transmission associated with the first transmission.
The ’565 application teaches the same automated generation of a subsequent communication relating to a prior message transmission as claim 15 of the present application, including detecting a condition associated with the message and generating a second communication conveying information about that message. Claim 15 of the present application differs in that the detected condition is unavailability of a transmission path and the subsequent communication conveys delivery information to the source device, rather than detecting a change in clinically relevant information and communicating an updated transmission to the target device. However, the ’565 application teaches generating a follow-up communication in response to a detected condition affecting a previously generated message. It would have been obvious to one of ordinary skill in the art to generate such a follow-up communication when other message-related conditions occur, including transmission failure or alternate routing, as this represents a predictable variation of the same messaging state-notification mechanism. Accordingly, claim 15 is an obvious variation of claim 1 of the ’565 application.
Claims 1, 8, and 15 are not identical to the claims of the ’565 patent but are not patentably distinct. The differences between the claims represent obvious variations of the same invention. Accordingly, claims 1, 8 and 15 are rejected under the doctrine of nonstatutory obviousness-type double patenting.
Claim Rejections - 35 USC § 112
Claims 2, 4-5, 7, 9, 11-12, 14, 16, 18, and 20 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.
Claim 2 recites “the request receipt element is further configured to indicate the identified second path or to indicate use of the identified second path by the control server in connection with responding to the request to transmit.”
This limitation requires that the receipt element convey information identifying the particular alternate transmission path (i.e., routing path information) used by the control server. The specification does not reasonably convey possession of this subject matter. The specification describes that when an optimal path is unavailable, an alternate path may be used and that a “push receipt” may notify the source device that an alternate path was used (see, the description corresponding to transmission 120 and push receipt 122). However, the disclosure indicates notifying that an alternate path occurred and does not describe the receipt element indicating the specific identified path, routing information, or any path-identifying data within the receipt. The described acknowledgements otherwise only indicate delivery status (device level acknowledgement or read receipt), not routing path information.
Accordingly, the specification fails to demonstrate possession of a request receipt element configured to indicate the identified second path, as presently claimed. Therefore, claim 2 lacks adequate written description support under 35 U.S.C. §112(a).
Claim 4 recites “wherein the payload comprises particular clinical information that is extracted via the source device.”
This limitation requires the source device to obtain or extract the clinical information used in the message payload. The specification does not reasonably convey possession of this subject matter. While the specification describes that messages may include clinical information, it does not describe the source device extracting or obtaining the clinical information for inclusion in the payload. The disclosure instead describes routing and handling of messages that contain clinical information, but does not attribute acquisition or extraction of the clinical information to the source device. Accordingly, the specification fails to demonstrate possession of a message payload containing clinical information extracted via the source device.
Therefore, claim 4 lacks adequate written description support under 35 U.S.C. §112(a).
Claim 5 recites “wherein the request receipt element corresponds to a push receipt that does not include the particular clinical information.”
The specification discloses that, when an optimal path is unavailable, an alternate path may be used and that the payload containing clinical information is not communicated through the alternate path; instead, a notification of the message is routed via the alternate transmission path. The specification further discloses that a push receipt may be sent to the source device to notify the source device that an alternate path was used. However, the specification does not describe the push receipt as excluding clinical information, nor does it indicate that the push receipt is limited to metadata or routing status information. The disclosure distinguishes the absence of clinical payload in the alternate path notification, but does not attribute that characteristic to the push receipt transmitted to the source device. Thus, the specification fails to demonstrate possession of a push receipt defined by the absence of the particular clinical information, as claimed.
Accordingly, the originally filed disclosure does not reasonably convey to one of ordinary skill in the art that the inventor possessed a request receipt element corresponding to a push receipt that does not include the particular clinical information. Therefore, claim 5 lacks adequate written description support under 35 U.S.C. §112(a).
Claim 7 recites “wherein the request receipt element corresponds to a push receipt configured to notify the source device with content indicating that an alternate path, corresponding to the identified second path, has been identified via the control server.”
This limitation requires a receipt notifying the source device that the control server has identified an alternate transmission path. The specification does not reasonably convey possession of this subject matter. The specification describes that when an optimal path is unavailable, an alternate path may be used and that a push receipt may notify the source device that an alternate path was used. However, the disclosure does not describe notifying the source device that an alternate path has been identified, nor does it disclose a receipt conveying routing-selection information independent of message transmission. The described notification is tied only to use of the alternate path after routing occurs, not to identification of the path itself.
Accordingly, the specification fails to demonstrate possession of a push receipt configured to notify the source device that an alternate path has been identified, as presently claimed. Therefore, claim 7 lacks adequate written description support under 35 U.S.C. §112(a).
Claims 9 and 16 are analogous to claim 2, thus claims 9 and 16 are similarly analyzed and rejected in a manner consistent with the rejection of claim 2.
Claim 11 is analogous to claim 4, thus claim 11 is similarly analyzed and rejected in a manner consistent with the rejection of claim 4.
Claim 12 is analogous to claim 5, thus claim 12 is similarly analyzed and rejected in a manner consistent with the rejection of claim 5.
Claims 14 and 20 are analogous to claim 7, thus claims 14 and 20 are similarly analyzed and rejected in a manner consistent with the rejection of claim 7.
Claim 18 is analogous to claims 4 and 5, thus claim 18 is similarly analyzed and rejected in a manner consistent with the rejection of claims 4 and 5.
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 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 manage the delivery of a communication by determining when a communication attempt has failed, selecting an alternative contact path, and informing the sender of the communication status. This is a method of coordinating interpersonal communication according to rules for message routing and notification. The mere nominal recitation of a generic hardware processor associated with a control server does not take the claim out of the methods of certain methods of organizing human activity. Thus, the claim recites an abstract idea.
Alternatively, claim 1 recites the limitations of determining that a first path for transmitting the message to a target endpoint address is unavailable; in response to determining that the first path to the target endpoint address is unavailable, identifying a second path to the target endpoint address; and
based on identifying the second path to the target endpoint address: pushing request receipt element configured to indicate at least (a) content corresponding to the message or (b) delivery information with respect to the target endpoint address or with respect to the message. These limitations, as drafted, are processes that, under their broadest reasonable interpretation, cover performance of the limitations in the mind or by using a pen and paper. But for the “via one or both of the at least one hardware processor and the control server” language, the claim encompasses a user evaluating whether a communication attempt failed, selecting an alternative way to contact the recipient, and informing the sender of the communication status in their mind or by using a pen and paper. The mere nominal recitation of one or both of the at least one hardware processor and the control server does not take the claim limitations out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
Independent claim 8 and 15 recite 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:
detecting, via at least one hardware processor associated with a control server and further associated with a medical environment, a request from a source device to transmit a message to a destination associated with a target device, wherein the control server and the destination are in separate domains associated with the medical environment;
determining that a first path for transmitting the message to a target endpoint address associated with the target device is unavailable;
in response to determining that the first path to the target endpoint address is unavailable, identifying a second path to the target endpoint address; and
based on identifying the second path to the target endpoint address: pushing, to the source device via one or both of the at least one hardware processor and the control server, request receipt element configured to indicate at least
(a) content corresponding to the message or
(b) delivery information with respect to the target endpoint address or with respect to the message.
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 managing communication delivery and notification after a failed transmission attempt in a computer environment. The claimed computer components (i.e., via at least one hardware processor associated with a control server; from a source device; associated with a target device; and to the source device via one or both of the at least one hardware processor and the control server) are recited at a high level of generality and are merely invoked as tools to perform an existing process of coordinating communication routing and informing a sender of message status. 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 communication network 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 further associated with a 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 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 managing communication delivery and notification after a failed transmission attempt 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. The claim is not patent eligible.
Claims 5-6, 12-13, 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 2-4, 7, 9-11, 14, 16-18, and 20 recite the additional elements of by the control server (claims 2, 9, and 16), by the source device (claims 3, 10, and 17), via the source device (claims 4, 11, and 18), via the control server (claims 7, 14, and 20) . However, this additional element amounts 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] “In several embodiments, a method of making patient care messages available to healthcare providers on different shifts includes electronically generating a provider assignment user interface for presentation to a user.”), comprising:
detecting, via at least one hardware processor associated with a control server and further associated with a medical environment, a request from a source device to transmit a message to a destination associated with a target device, wherein the control server and the destination are in separate domains associated with the medical environment (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 [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 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 determining that a first path for transmitting the message to a target endpoint address associated with the target device is unavailable; in response to determining that the first path to the target endpoint address is unavailable, identifying a second path to the target endpoint address; based on identifying the second path to the target endpoint address: pushing, to the source device via one or both of the at least one hardware processor and the control server, request receipt element configured to indicate at least (a) content corresponding to the message or (b) delivery information with respect to the target endpoint address or with respect to the message.
Kim teaches determining that a first path for transmitting the message to a target endpoint address associated with the target device is unavailable (Kim, Col. 6, lines 16-32, “Client computer 101 may include virtually any computing device capable of communicating over a network to send and receive information, including messaging, performing various online actions, or the like. The set of such devices may include devices that typically connect using a wired or wireless communications medium such as personal computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network Personal Computers (PCs), or the like. In one embodiment, at least some of client computers 102-104 may operate over wired and/or wireless network. Today, many of these devices include a capability to access and/or otherwise communicate over a network such as network 111 and/or even wireless network 110. Moreover, client computers 102-104 may access various computing applications, including a browser, or other web-based application.”, 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.”);
in response to determining that the first path to the target endpoint address is unavailable, identifying a second path to the target endpoint address (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 based on identifying the second path to the target endpoint address: pushing, to the source device via one or both of the at least one hardware processor and the control server, request receipt element configured to indicate at least (a) content corresponding to the message or (b) delivery information with respect to the target endpoint address or with respect to the message (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 a person of ordinary skill in the art to combine the healthcare messaging system of Rybkin with the routing resiliency techniques of Kim. Rybkin teaches a medical environment messaging server that receives communication requests from client devices and routes messages to appropriate care providers across institutional networks and external systems, which detecting a request to transmit a message between devices operating in different domains. However, Rybkin does not expressly address handling situations where a primary transmission path is unavailable. Kim teaches determining that a preferred messaging provider or communication path is unavailable and, in response, selecting a fallback provider or alternate routing path to ensure message delivery reliability. A skilled artisan would have been motivated to incorporate Kim’s alternate path routing into Rybkin because healthcare communications are time critical and system reliability is a well recognized design objective; applying known failover routing techniques to an existing medical messaging system represents the predictable use of prior art elements according to their established functions.
It also would have been obvious to further incorporate the acknowledgement feedback techniques of Underwood into the combined system. Underwood teaches that a delivery server returns an acknowledgement or delivery status message to the originating device after attempting message delivery, including after routing through alternate delivery channels. A skilled artisan would have recognized that once Rybkin’s medical messaging system is modified to reroute communications using Kim’s fallback path, the sender must be informed of message content or delivery status so the user can confirm receipt or take corrective action if needed. Providing confirmation feedback to the sending device is a known reliability improvement in communication systems, and integrating Underwood’s acknowledgement mechanism into the Rybkin and Kim combination would therefore have been a predictable enhancement yielding improved reliability of clinical communications.
Regarding claim 2, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein the request receipt element is further configured to indicate the identified second path or to indicate use of the identified second path by the control server in connection with responding to the request to transmit (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.” and
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 a person of ordinary skill in the art to combine Kim with Underwood. Kim teaches identifying and using a fallback message provider when a preferred provider is unavailable (using a second transmission path). Underwood teaches that, after attempting delivery, including via an alternate channel when the primary channel fails, a server sends an acknowledgement to the originating device indicating delivery status. A skilled artisan would have incorporated Underwood’s acknowledgement mechanism into Kim’s failover routing system to improve reliability and inform the sender that transmission succeeded despite primary path failure. This combination represents the predictable use of known messaging reliability techniques, which renders obvious indicating to the source device that the second path was used.
Regarding claim 3, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein the message is generated based on one or more electronic medical records that are stored at the medical environment and that are accessible by the source device (Rybkin [0049] “Messages may take various forms. Message subtypes may include (but are not limited to) comments, questions, tasks, events, problems, medications, and allergies. Many other subtypes are possible. By representing various forms of medical data as messages, the aggregator 120 can utilize its capacity for dynamically routed reminders, notifications and actions to make medical data more interactive. For example, when recording a potentially harmful medication in the aggregator 120 (as a message subtype), a provider can set a dynamically routed reminder for someone in the future to check labs or otherwise monitor for expected complication.” 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).”).
It would have been obvious to a person of ordinary skill in the art to implement the claimed feature in view of Bybkin. Bybkin teaches a healthcare messaging system integrated with an eelctronic medical record (EMR) in which medical record data (medications, problems, allergies) is incorporated into messages and used to generate reminders and notifications. Bybkin further discloses that users access the system through client devices via an EMR application, thereby allowing the source device to access the medical records stored within the medical environment. A skilled artisan would have recognized that generating messages from EMR data accessible to the originating device improves clinical communication and workflow efficiency. Using accessible electronic medical record information as the basis for message generation represents the predictable use of known healthcare messaging techniques and therefore renders obvious generating the message based on EMR data accessible by the source device.
Regarding claim 4, Rybkin, Kim, and Underwood teach the invention in claim 3, as discussed above, and further teach wherein the message is configured to indicate a payload, and wherein the payload comprises particular clinical information that is extracted via the source device (Rybkin [0049] “Messages may take various forms. Message subtypes may include (but are not limited to) comments, questions, tasks, events, problems, medications, and allergies. Many other subtypes are possible. By representing various forms of medical data as messages, the aggregator 120 can utilize its capacity for dynamically routed reminders, notifications and actions to make medical data more interactive. For example, when recording a potentially harmful medication in the aggregator 120 (as a message subtype), a provider can set a dynamically routed reminder for someone in the future to check labs or otherwise monitor for expected complication.” 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).”).
Bybkin teaches incorporating clinical information from electronic medical records, including medications and problems, into messages used for reminders and notifications within clinical workflows. Because providers access and generate such communications through client devices connected to the electronic medical record (EMR), a person of ordinary skill in the art would have found it obvious that the clinical information forming the message payload is obtained at the sending device during message creation. Implementing the payload as clinical information extracted via the source device therefore represents the predictable use of conventional clinical messaging interfaces according to their ordinary function.
Regarding claim 5, Rybkin, Kim, and Underwood teach the invention in claim 4, as discussed above, and further teach wherein the request receipt element corresponds to a push receipt that does not include the particular clinical information (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 a person of ordinary skill in the art to implement the request receipt element of claim 4 as a push receipt that does not include the particular clinical information in view of Underwood. Underwood teaches that after a message is transmitted, the delivery server sends an acknowledgement to the originating device indicating delivery status. Because this acknowledgement is a delivery confirmation separate from the transmitted message, it conveys only delivery information rather than the message payload itself. A POSITA would have understood that including the full message content within the acknowledgement would defeat the purpose of a receipt and unnecessarily duplicate network traffic. Thus, the acknowledgement implicitly omits the clinical information contained in the message, representing the predictable and conventional operation of messaging systems.
Regarding claim 6, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach the request receipt element comprises the delivery information (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 a person of ordinary skill in the art to configure the request receipt element to comprise delivery information in view of Underwood. Underwood teaches that after a message is transmitted, the delivery server sends an acknowledgement to the originating device advising the sender of successful end-to-end delivery of the message. Providing delivery status feedback to the sender represents a well known feature of messaging systems to confirm transmission reliability and inform the sender whether further action is necessary. Accordingly, incorporating delivery information within the receipt element would have been an obvious implementation of known acknowledgement mechanisms to improve user awareness.
Regarding claim 7, Rybkin, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein the request receipt element corresponds to a push receipt configured to notify the source device with content indicating that an alternate path, corresponding to the identified second path, has been identified via the control server (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.” and
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.”).
Kim teaches identifying a fallback communication provider when a preferred path is unavailable. Underwood teaches transmitting an acknowledgement to the originating device indicating delivery status. A person of ordinary skill in the art would have found it obvious to include information indicating that an alternate path was selected within the acknowledgement, since messaging systems commonly provide status feedback to inform the sender how a message was handled and whether delivery reliability was affected. Providing routing status information represents a predictable variation of known acknowledgement mechanisms to improve user awareness and communication transparency.
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.
Claims 15-16 are analogous to claims 1-2, thus claims 15-16 are similarly analyzed and rejected in a manner consistent with the rejection of claims 1-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.
Claim 18 is analogous to claims 4 and 5, thus claim 18 is similarly analyzed and rejected in a manner consistent with the rejection of claims 4 and 5.
Claims 19-20 are analogous to claims 6-7, thus claims 19-20 are similarly analyzed and rejected in a manner consistent with the rejection of claims 6-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