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 final office action on merits is in response to the communication received on 04/27/2026. Claim 21 is new. Claim 5 is cancelled. Amendments to claims 1, 4, 8, and 15 are acknowledged and have been carefully considered. Claims 1-4, and 6-21 are pending and considered below.
Claim Rejections - 35 USC § 112
Claim 21 is 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 21 recites "based on receiving at least a first response, of a plurality of responses, associated with the transmission, electronically communicating to the source device an acknowledgement, wherein electronically communicating the acknowledgement comprises sending a device acknowledgement and a read acknowledgement." However, the specification does not disclose electronically communicating the device acknowledgement and the read acknowledgement based on receiving a first response. The specification only discloses electronically communicating the device acknowledgement and the read acknowledgement after receiving the device acknowledgement and the read acknowledgement from the intended target, while separately disclosing that responses received from the intended target are forwarded to the source device.
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 claim 21 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-4, and 6-21 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-4, and 6-7 are drawn to a method, claims 8-14, and 21 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 the limitations of (a) sending the message to the destination if the endpoint address for the destination can be identified or (b) delivering the request to a second node if the endpoint address for the destination cannot be identified; comparing, data associated with the request with data entries stored at a message protocol table; determining, based on the comparing, whether the endpoint address for the destination can be identified; in response to determining that the endpoint address for the destination can be identified: refraining from the delivering of the request; and sending the message to the destination, wherein sending the message to the destination comprises: (a) identifying an intended target associated with the endpoint address for the destination. These limitations, as drafted, are processes that, under their broadest reasonable interpretations, cover performance of the limitations in the mind or by using a pen and paper. Even when considering the “by the first node” language, the claim encompasses a user receiving a messaging request, comparing the request information to a routing directory or message protocol table, determining whether the destination can be identified, deciding whether to send the message directly or forward the request to another mode, and identifying the intended target, all of which can be practically performed in the mind or by using a pen and paper. The nominal recitation of “by the first node” does not take the claim limitations out of the mental processes grouping because it merely identifies the generic computer component performing the recited evaluations and decisions rather than changing the character of the recited operations. Thus, the claim recites a mental process which is an abstract idea.
Independent claims 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 claim 1, include:
detecting, via at least one processor of the one or more hardware processors associated with a first node and further associated with a medical environment, a request (a) from a source device within a first domain (b) to transmit a message to a destination associated with a second domain (c) without an endpoint address for the destination,
wherein the first node is configured to (a) send the message to the destination if the endpoint address for the destination can be identified by the first node or (b) deliver the request to a second node if the endpoint address for the destination cannot be identified by the first node;
comparing, by the first node, data associated with the request with data entries stored at a message protocol table;
determining, based on the comparing, whether the endpoint address for the destination can be identified;
in response to determining that the endpoint address for the destination can be identified: refraining from the delivering of the request to the second node; and
sending the message to the destination, wherein sending the message to the destination comprises:
(a) identifying an intended target associated with the endpoint address for the destination, wherein one or both of the destination and the intended target are discoverable within a network that is associated with the medical environment and that includes the second domain;
(b) generating a transmission for the intended target; and
(c) electronically communicating the transmission to the intended target within the second domain.
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 receiving a message request, comparing the request information with stored routing information, determining whether a destination can be identified, deciding whether to send the message or forward the request, and identifying an intended target in a computer environment. The claimed computer components (i.e., via at least one processor of the one or more hardware processors associated with a first node, wherein the first node is configured to, by the first node, to the second node, wherein one or both of the destination and the intended target are discoverable within a network; and that includes the second domain) are recited at a high level of generality and are merely invoked as tools to perform a process of evaluating routing information, determining message routing, and identifying the intended recipient. 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 environment and associated network), 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 that is 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 elements of detecting a request (a) from a source device within a first domain (b) to transmit a message to a destination associated with a second domain (c) without an endpoint address for the destination; (b) generating a transmission for the intended target; and (c) electronically communicating the transmission to the intended target within the second domain. These limitations are recited at a high level of generality (i.e., as a general means of receiving information and communicating the result of the abstract idea), and amounts to mere data gathering and insignificant application, which are forms of insignificant extra-solution activities. Accordingly, even 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 receiving a message request, comparing the request information with stored routing information, determining whether a destination can be identified, deciding whether to send the message or forward the request, and identifying an intended target 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 elements of detecting a request (a) from a source device within a first domain (b) to transmit a message to a destination associated with a second domain (c) without an endpoint address for the destination; (b) generating a transmission for the intended target; and (c) electronically communicating the transmission to the intended target within the second domain have been evaluated. The method comprising at least one processor performs a general function of receiving messaging information for processing and electronically communicating the results of that processing, which represents a well-understood, routine, and conventional activity in the field of computer networking and electronic communications. 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 [0015]). 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 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 evaluating routing information and communicating the resulting transmission, and therefore does not integrate the abstract idea into a practical application. Additionally, as noted in In re Brown, 645 Fed. App'x 1014, 1016-1017 (Fed. Cir. 2016), merely transmitting information represents an insignificant application of the underlying mental process, as they are merely outputting results of the abstract idea and do not impose any meaningful limitation or provide any technological improvement. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 3, 10, and 17 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, 6-7, 9, 11-14, 16, 18-21 recite the additional elements of from the source device (claims 2, 9, 16, 21), via the one or more hardware processors (claims 4, 6, 11-13, and 18-20), the network (claims 7 and 14). 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 previously identified additional elements, 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 claims are 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-4, and 6-21 are rejected under 35 U.S.C. 103 as being unpatentable over Hartman et al. (U.S. Patent 9235547 B1), referred to hereinafter as Hartman, in view of Dorsey et al. (U.S. Patent 9577966 B1), referred to hereinafter as Dorsey, and Rybkin (U.S. Patent Publication 2016/0004836 A1), referred to hereinafter as Rybkin.
Regarding claim 1, Hartman teaches a computer-implemented method-performed by one or more hardware processors, the computer-implemented method comprising (Hartman, Col. 12, “The above exemplary messaging system may implement a message routing/delivery method as generally illustrated in FIG. 4 (0400), wherein the messaging method comprises the following steps:”
Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”):
detecting, via at least one processor of the one or more hardware processors associated with a first node and further associated with a medical environment, a request (a) from a source device (b) to transmit a message (Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”);
wherein the first node is configured to (a) send the message to the destination (Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”);
Hartman fails to explicitly teach within a first domain; (b) to transmit a message to a destination associated with a second domain (c) without an endpoint address for the destination; destination if the endpoint address for the destination can be identified by the first node or (b) deliver the request to a second node if the endpoint address for the destination cannot be identified by the first node; comparing, by the first node, data associated with the request with data entries stored at a message protocol table; determining, based on the comparing, whether the endpoint address for the destination can be identified; in response to determining that the endpoint address for the destination can be identified: refraining from the delivering of the request to the second node; sending the message to the destination, wherein sending the message to the destination comprises: (a) identifying an intended target associated with the endpoint address for the destination, wherein one or both of the destination and the intended target are discoverable within a network that is associated with the medical environment and that includes the second domain; (b) generating a transmission for the intended target; .”); and (c) electronically communicating the transmission to the intended target within the second domain.
Dorsey teaches (c) without an endpoint address for the destination (Dorsey, Col. 1-Col. 2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”);
if the endpoint address for the destination can be identified by the first node (Dorsey, Col. 1- 2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”);
comparing, by the first node, data associated with the request with data entries stored at a message protocol table (Dorsey, Col. 5-6, “The user lookup module 204 retrieves destination and receipt preference information for each recipient of the message and attaches this information to the message for further processing by the system. The message is received by the rules module 208, which applies rules to further determine where the message is to be sent. The rules module 208 processes the preferences specified by each recipient. For example, if a recipient specified that it wanted to receive at most 10 e-mails per day, the rules module would determine if this daily threshold has been reached. If it has been, then the message would not be sent by e-mail, and the rules module would remove the e-mail destination address for that recipient for this message. The rules module 208 also applies global rules to the message and destination addresses. These global rules are specified in the rules database 210, which can be populated by a system administrator. Examples of global limits include a maximum number of messages that a user can send or receive per day or a maximum message length. Also, system wide limits can be imposed on messages. For example, a maximum number of SMS messages (sent by all users) to cell phones with Verizon service can be sent by the system per month. The rules module will enforce this rule, possibly by removing some Verizon SMS recipients from low priority messages when the number of messages is approaching the monthly limit. The translation module 212 receives messages from the rules module 208 and processes the content of the messages based on the needs or preferences of the recipients. FIG. 3 illustrates one embodiment of the translation module 212. The translation module 212 modifies the body of the message so that it is compatible with and easy to view on the destination endpoint 114. Since a single message may be sent to multiple endpoints, the translation module may produce copies of the message, process them differently, and send the differently translated copies to different endpoints (e.g., one to IM recipients and one to SMS recipients”);
determining, based on the comparing, whether the endpoint address for the destination can be identified (Dorsey, Col. 1-2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user. The system beneficially allows for device independent point to multipoint communication. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A receiving user controls that user's destination endpoint and receipt preferences. A message can be translated for improved viewing on a particular destination endpoint. Additionally, advertisements can be provided to users based on user activity in the system.”);
in response to determining that the endpoint address for the destination can be identified: refraining from the delivering of the request to the second node (Dorsey, Col. 1-2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”);
sending the message to the destination, wherein sending the message to the destination comprises: (a) identifying an intended target associated with the endpoint address for the destination (Dorsey, Col. 1-2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”
Dorsey, Col. 5-6, “The user lookup module 204 retrieves destination and receipt preference information for each recipient of the message and attaches this information to the message for further processing by the system. The message is received by the rules module 208, which applies rules to further determine where the message is to be sent. The rules module 208 processes the preferences specified by each recipient. For example, if a recipient specified that it wanted to receive at most 10 e-mails per day, the rules module would determine if this daily threshold has been reached. If it has been, then the message would not be sent by e-mail, and the rules module would remove the e-mail destination address for that recipient for this message. The rules module 208 also applies global rules to the message and destination addresses. These global rules are specified in the rules database 210, which can be populated by a system administrator. Examples of global limits include a maximum number of messages that a user can send or receive per day or a maximum message length. Also, system wide limits can be imposed on messages. For example, a maximum number of SMS messages (sent by all users) to cell phones with Verizon service can be sent by the system per month. The rules module will enforce this rule, possibly by removing some Verizon SMS recipients from low priority messages when the number of messages is approaching the monthly limit. The translation module 212 receives messages from the rules module 208 and processes the content of the messages based on the needs or preferences of the recipients. FIG. 3 illustrates one embodiment of the translation module 212. The translation module 212 modifies the body of the message so that it is compatible with and easy to view on the destination endpoint 114. Since a single message may be sent to multiple endpoints, the translation module may produce copies of the message, process them differently, and send the differently translated copies to different endpoints (e.g., one to IM recipients and one to SMS recipients).”);
(b) generating a transmission for the intended target (Dorsey, Col. 1-2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”, and
Dorsey, Col. 5-6, “The user lookup module 204 retrieves destination and receipt preference information for each recipient of the message and attaches this information to the message for further processing by the system. The message is received by the rules module 208, which applies rules to further determine where the message is to be sent. The rules module 208 processes the preferences specified by each recipient. For example, if a recipient specified that it wanted to receive at most 10 e-mails per day, the rules module would determine if this daily threshold has been reached. If it has been, then the message would not be sent by e-mail, and the rules module would remove the e-mail destination address for that recipient for this message. The rules module 208 also applies global rules to the message and destination addresses. These global rules are specified in the rules database 210, which can be populated by a system administrator. Examples of global limits include a maximum number of messages that a user can send or receive per day or a maximum message length. Also, system wide limits can be imposed on messages. For example, a maximum number of SMS messages (sent by all users) to cell phones with Verizon service can be sent by the system per month. The rules module will enforce this rule, possibly by removing some Verizon SMS recipients from low priority messages when the number of messages is approaching the monthly limit. The translation module 212 receives messages from the rules module 208 and processes the content of the messages based on the needs or preferences of the recipients. FIG. 3 illustrates one embodiment of the translation module 212. The translation module 212 modifies the body of the message so that it is compatible with and easy to view on the destination endpoint 114. Since a single message may be sent to multiple endpoints, the translation module may produce copies of the message, process them differently, and send the differently translated copies to different endpoints (e.g., one to IM recipients and one to SMS recipients.”);
(c) electronically communicating the transmission to the intended target (Dorsey, Col. 1-2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”, and
Dorsey, Col. 5-6, “The user lookup module 204 retrieves destination and receipt preference information for each recipient of the message and attaches this information to the message for further processing by the system. The message is received by the rules module 208, which applies rules to further determine where the message is to be sent. The rules module 208 processes the preferences specified by each recipient. For example, if a recipient specified that it wanted to receive at most 10 e-mails per day, the rules module would determine if this daily threshold has been reached. If it has been, then the message would not be sent by e-mail, and the rules module would remove the e-mail destination address for that recipient for this message. The rules module 208 also applies global rules to the message and destination addresses. These global rules are specified in the rules database 210, which can be populated by a system administrator. Examples of global limits include a maximum number of messages that a user can send or receive per day or a maximum message length. Also, system wide limits can be imposed on messages. For example, a maximum number of SMS messages (sent by all users) to cell phones with Verizon service can be sent by the system per month. The rules module will enforce this rule, possibly by removing some Verizon SMS recipients from low priority messages when the number of messages is approaching the monthly limit. The translation module 212 receives messages from the rules module 208 and processes the content of the messages based on the needs or preferences of the recipients. FIG. 3 illustrates one embodiment of the translation module 212. The translation module 212 modifies the body of the message so that it is compatible with and easy to view on the destination endpoint 114. Since a single message may be sent to multiple endpoints, the translation module may produce copies of the message, process them differently, and send the differently translated copies to different endpoints (e.g., one to IM recipients and one to SMS recipients.”).
Rybkin teaches within a first domain; (b) to transmit a message to a destination associated with a second domain (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).”, and
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.”);
(b) deliver the request to a second node if the endpoint address for the destination cannot be identified by the first node (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 [0023] “Referring to FIG. 2A, to facilitate the handoff and messaging functionality, the aggregator 120 can monitor symbolic links between the providers and the patients and store these links in a database. As the totality of symbolic links may be constantly changing in real time (or near real time) in response to input by a plurality of providers 232 upon a plurality of patients 234, this is not a function that can be adequately performed by a human being as a mental process. When a provider 232 wishes to send a message about a patient 234, the aggregator 120 can consult a database having a table of doctor links 222 and a table of patient links 224. The aggregator 120 can access these tables to retrieving the symbolic links between the patient and the current responsible providers. The aggregator 120 can dynamically aggregate this information using an integration component 226 to construct a list of the providers 232 who are currently responsible for a given patient 234.”
Rybkin [0024] “The aggregator 120 also has the capability in several embodiments to route messages to the responsible provider 232. Therefore, the aggregator 120 can allow sending of messages without prospective knowledge of the recipient. The messages are routed automatically to the provider 232 in charge at any one time. In one embodiment, these messages may include notifications and reminders (of tasks to be performed, laboratory studies to be checked, etc.), which are scheduled without advance knowledge of the recipient. The aggregator 120 determines the correct recipient at the scheduled time (see, e.g., below with respect to FIG. 3B.”);
wherein one or both of the destination and the intended target are discoverable within a network that is associated with the medical environment and that includes the second domain (Rybkin [0023] “Referring to FIG. 2A, to facilitate the handoff and messaging functionality, the aggregator 120 can monitor symbolic links between the providers and the patients and store these links in a database. As the totality of symbolic links may be constantly changing in real time (or near real time) in response to input by a plurality of providers 232 upon a plurality of patients 234, this is not a function that can be adequately performed by a human being as a mental process. When a provider 232 wishes to send a message about a patient 234, the aggregator 120 can consult a database having a table of doctor links 222 and a table of patient links 224. The aggregator 120 can access these tables to retrieving the symbolic links between the patient and the current responsible providers. The aggregator 120 can dynamically aggregate this information using an integration component 226 to construct a list of the providers 232 who are currently responsible for a given patient 234.”
Rybkin [0024] “The aggregator 120 also has the capability in several embodiments to route messages to the responsible provider 232. Therefore, the aggregator 120 can allow sending of messages without prospective knowledge of the recipient. The messages are routed automatically to the provider 232 in charge at any one time. In one embodiment, these messages may include notifications and reminders (of tasks to be performed, laboratory studies to be checked, etc.), which are scheduled without advance knowledge of the recipient. The aggregator 120 determines the correct recipient at the scheduled time (see, e.g., below with respect to FIG. 3B).”
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.”);
within the second domain (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.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the medical messaging system of Hartman to incorporate the endpoint independent routing techniques taught by Dorsey and the dynamic recipient determination techniques taught by Rybkin. Hartman teaches a computer implemented messaging system operating in a medical environment for receiving, routing, and delivering messages between users, but does not disclose routing messages without requiring the sender to know endpoint specific addresses or dynamically determining the responsible recipient based on current healthcare assignments. Dorsey teaches a routing engine that determines destination users and their corresponding communication endpoints without requiring the sender to know endpoint specific user addresses, while applying routing rules and transmitting messages to the appropriate endpoints. Rybkin further teaches dynamically determining the appropriate healthcare provider by consulting provider and patient association information and automatically routing messages to the provider currently responsible for the patient without requiring advance knowledge of the recipient.
A person of ordinary skill in the art would have been motivated to combine these teachings to improve the flexibility and efficiency of Hartman's medical messaging system by enabling automatic endpoint determination and dynamic recipient selection across multiple communication endpoints and healthcare environments. Incorporating Dorsey's endpoint independent routing into Hartman's messaging architecture would have eliminated the need for message originators to maintain endpoint specific addressing information while allowing the system to automatically identify appropriate communication endpoints. Further incorporating Rybkin's dynamic healthcare routing would have enabled the system to identify the appropriate responsible provider at the time of message delivery, which improves the reliability of message routing in environments where provider assignments frequently change. The combination applies known routing and recipient selection techniques according to their established functions to obtain the predictable result of automatically routing messages to the appropriate destination without requiring prior knowledge of endpoint addresses or current recipient assignments.
Regarding claim 2, Hartman, Dorsey, and Rybkin teach the invention in claim 1, as discussed above, and further teach wherein the request originates from the source device in the first domain and does not indicate the endpoint address of the destination associated with the second domain, and wherein a second response is electronically communicated from the intended target to the source device (Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”,
Hartman, Col. 9, “The present invention in many preferred embodiments assumes that the message delivery thread hierarchy is fully defined such that there is never a “message delivery failure” in the context of a transmitted message never reaching and being acknowledged by at least one message recipient. However, some alternative embodiments may utilize message hierarchy threads that permit “dead” messages to be acknowledged as “undeliverable” if none of the targeted message recipients are available or capable of acknowledging the message.”,
Hartman, Col. 11, “Key to this description is the ability of the described invention to guarantee message delivery to the appropriate message recipient and appropriately inform the message originator of message reception and acknowledgement by the message recipient. This capability is essential to ensure that messages that are of a mission-critical and/or life-critical nature are appropriately received and acted upon by appropriate message recipients.”, and
Dorsey, Col. 1- 2, “Disclosed is a system (and/or method) that includes, for example, a routing engine that receives a message from any of various entry points, including e-mail, short message service (SMS), instant messenger (IM), web input, and application programming interface (API) function calls. The routing engine determines the identities of the destination users to receive the message, possibly by expanding destination groups. The routing engine determines the endpoints on which the destination users wish to receive the message, the endpoints can be one or more of e-mail, SMS, IM, web input, and API function calls. The destination endpoints are independent of the source entry points, and the message sender does not need to have knowledge of the endpoints, or endpoint-specific user addresses. A single user can receive a message at multiple endpoints. The routing engine applies rules to the message to determine the actual destination endpoints for each user, translates the message as appropriate for each endpoint, and transmits the message to the endpoints, where the message is delivered to the destination user.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the medical messaging system of Hartman to incorporate the endpoint independent routing techniques taught by Dorsey. Hartman teaches a medical messaging system in which a message originates from a message originator, is routed to an intended message recipient, and the message originator is informed of the recipient's message reception and acknowledgement, but does not disclose that the message sender need not specify endpoint specific user addresses. Dorsey teaches a routing engine that automatically determines destination endpoints without requiring the sender to know endpoint specific addresses while routing messages to the appropriate destination. A person of ordinary skill in the art would have been motivated to combine these teachings to improve the flexibility of Hartman's messaging system by reducing the burden on message originators to maintain endpoint specific addressing information while preserving Hartman's capability of notifying the message originator when the intended recipient receives and acknowledges the message. The combination applies known routing techniques according to their established functions to achieve the predictable result of automatically routing messages to the appropriate recipient and communicating the recipient's acknowledgement back to the message originator.
Regarding claim 3, Hartman, Dorsey, and Rybkin teach the invention in claim 1, as discussed above, and further teach wherein the second domain differs from the first domain, and wherein the destination is within the second domain (Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”, and
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.”).
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 Hartman to incorporate the cross domain communication techniques taught by Rybkin. Hartman teaches transmitting messages from a message originator through a communications network to a remote message recipient, while Rybkin teaches secure messaging among different healthcare institutions and network environments, including communications between local area networks, wide area networks, and multiple clinical facilities. One of ordinary skill in the art would have been motivated to combine these teachings to improve the flexibility, scalability, and interoperability of Hartman's messaging system by enabling communications across different communication domains while ensuring that messages are delivered to recipients within the appropriate destination domain. The combination applies known networking and messaging techniques according to their established functions to achieve the predictable result of routing messages between different domains in a distributed healthcare communication environment.
Regarding claim 4, Hartman, Dorsey, and Rybkin teach the invention in claim 1, as discussed above, and further teach further comprising determining, via the one or more hardware processors, whether the destination is associated with a role, wherein the intended target is identified, via the one or more hardware processors, based on the determination that the destination is associated with the role (Hartman, Col. 19, “Under normal circumstances, the present invention processes messages by sequentially transmitting the message to addresses contained in a hierarchical target message address list. After each transmission, a predefined amount of time is allocated to determine if a response to the message has been received by the host message processor. If no response message is received (or if the response indicates that the message should be passed thru or passed around) the next address in the hierarchical target message address list is selected as the target for the message. This process continues until a successful response/action message is received from a targeted system interface”,
Hartman, Col. 26-27 “A typical example of a message delivery architecture is illustrated in FIG. 23 (2300), wherein a Severity+message (2301) is generated to indicate a FIRE AND MAN DOWN (2302). This message is broadcast (in parallel transmission mode) to 911 FIRE (2303), 911 RESCUE (2304), INTERNAL SECURITY (2305), HR PUBLIC RELATIONS (2306), and CONTINUING EXCELLENCE ACCIDENT INVESTIGATION (2307). Within these groups, serial cascade message transmission is directed towards individual chains of recipients within the various organizations (CORPORATE DUTY OFFICER (2308), VP OPS (2309); HR PUBLIC RELATIONS ACTION TEAM (2310), VP FINANCE (2311); ACCIDENT INVESTIGATION TEAM (2312), VP SAFETY (2313)). In this manner the message is properly broadcast to both the BREADTH and DEPTH necessary to address the critical situation, without necessarily waiting on any particular message recipient to act independently of the remaining message recipients.”, and
Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to implement the role message routing described by Hartman within the computerized messaging architecture of Hartman. Hartman teaches transmitting messages through a communication server to remote recipients and further teaches routing messages to organizational groups and individual recipients based on predefined responsibilities, such as emergency response groups and corporate duty officers, with messages being sequentially directed through hierarchical recipient lists until an appropriate recipient responds. One of ordinary skill in the art would have recognized that determining whether a destination is associated with a particular organizational role and identifying the intended target based on that role improves the efficiency of message delivery by ensuring that messages are automatically directed to personnel having the appropriate responsibilities. Applying such role recipient identification within Hartman's messaging system would have been a predictable use of known message routing techniques according to their established functions.
Regarding claim 6, Hartman, Dorsey, and Rybkin teach the invention in claim 1, as discussed above, and further teach further comprising detecting, via the one or more hardware processors, presence information associated with the intended target prior to the communication of the transmission (Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”, and
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.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the computerized messaging system of Hartman to incorporate the recipient status determination techniques taught by Rybkin. Hartman teaches a computer implemented messaging architecture in which a communication server transmits messages from a message originator to a remote message recipient over a communications network, while Rybkin teaches determining presence information associated with an intended target by consulting a status monitor database to determine whether a doctor is currently on duty or otherwise available prior to delivering the message. One of ordinary skill in the art would have been motivated to combine these teachings to improve the efficiency and reliability of message delivery by ensuring that messages are transmitted only to intended targets that are currently available, which reduce unnecessary message transmissions, minimizing delays caused by unavailable recipients, and facilitating timely delivery to appropriate personnel. The combination applies known recipient availability detection techniques to Hartman's messaging framework according to their established functions to achieve the predictable result of communicating messages more effectively to available intended targets.
Regarding claim 7, Hartman, Dorsey, and Rybkin teach the invention in claim 1, as discussed above, and further teach wherein the network includes the first domain and the second domain, wherein the second domain is disconnected from the first domain, and wherein the destination is discoverable within the network (Hartman, Col. 10, “The most general system overview of the present invention can be understood by the generalized system block structure illustrated in FIG. 1 (0100). In this generalized system structure, the message originator (0110) interfaces with a message entry interface (0101) under control of a communication process (0102) managed on a communication server (0103) that typically operates under control of software derived from a computer-readable medium (0104). Once a message has been entered by the message originator (0110) into the message entry interface (0101), it is then communicated using a communications network (0105) under control of the communications process (0102) and associated communications server (0103) to a remote client presentation interface (0106) for review/acceptance by a message recipient (0111).”
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.”, and
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.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the computerized messaging system of Hartman to incorporate the distributed healthcare networking and destination discovery techniques taught by Rybkin. Hartman teaches transmitting messages through a communications network from a message originator to a remote message recipient, while Rybkin teaches messaging among multiple healthcare institutions connected through local area networks, wide area networks, firewalls, and cloud infrastructure, as well as determining an appropriate destination by consulting association tables and recipient status information before message delivery. One of ordinary skill in the art would have been motivated to combine these teachings to improve the scalability and reliability of Hartman's messaging system by enabling communication across separate network domains while allowing the appropriate destination to be dynamically discovered within the distributed network rather than requiring a predetermined endpoint. The combination applies known distributed networking and recipient discovery techniques according to their established functions to achieve the predictable result of efficient message routing across multiple network domains to an appropriate destination.
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-17 are analogous to claims 1-3, thus claims 15-17 are similarly analyzed and rejected in a manner consistent with the rejection of claims 1-3.
Claims 18-19 are analogous to claim 4, thus claims 18-19 are similarly analyzed and rejected in a manner consistent with the rejection of claim 4.
Claim 20 is analogous to claim 6, thus claim 20 is similarly analyzed and rejected in a manner consistent with the rejection of claim 6.
Regarding claim 21, Hartman, Dorsey, and Rybkin teach the invention in claim 8, as discussed above, and further teach wherein the operations further comprise: based on receiving at least a first response, of a plurality of responses, associated with the transmission, electronically communicating to the source device an acknowledgement, wherein electronically communicating the acknowledgement comprises sending a device acknowledgement and a read acknowledgement (Hartman, Col. 9, “The present invention in many preferred embodiments assumes that the message delivery thread hierarchy is fully defined such that there is never a “message delivery failure” in the context of a transmitted message never reaching and being acknowledged by at least one message recipient. However, some alternative embodiments may utilize message hierarchy threads that permit “dead” messages to be acknowledged as “undeliverable” if none of the targeted message recipients are available or capable of acknowledging the message.”,
Hartman, Col. 11, “Key to this description is the ability of the described invention to guarantee message delivery to the appropriate message recipient and appropriately inform the message originator of message reception and acknowledgement by the message recipient. This capability is essential to ensure that messages that are of a mission-critical and/or life-critical nature are appropriately received and acted upon by appropriate message recipients.”, and
Rybkin [0048] “In the depicted embodiment, the message user interface 700 also contains a select box control 714 that enables the user to request a notification in the event that nobody looked at the message within a selectable time frame. This notification can be another message, which the aggregator 120 automatically sends to the sender of the original message if certain conditions are met (e.g., if the specified time interval has elapsed and/or the message was not accessed by other providers). This notification can be a fail-safe mechanism for communicating desired health information, which allows making sure that a high-priority message is received. The recipients have the option to identify to the aggregator 120 that they viewed the message, thereby providing a return receipt, which may not directly sent back to the sender, but may be stored in a database. The aggregator 120 can also identify to the original sender whether the recipient viewed or accessed the message but did not act on it.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the computerized messaging system of Hartman to incorporate the message receipt notification techniques taught by Rybkin. Hartman teaches electronically communicating acknowledgements to a message originator upon receipt and acknowledgement of a transmitted message, while Rybkin teaches providing return receipts and notifications indicating whether a recipient viewed or accessed a message, including communicating such information back to the original sender. One of ordinary skill in the art would have been motivated to combine these teachings to improve the reliability of message delivery by providing more detailed acknowledgment information regarding both message delivery and message review, which enable message originators to verify not only that a message reached the recipient's device but also that it was accessed or read. The combination applies known message acknowledgment and receipt notification techniques according to their established functions to achieve the predictable result of providing enhanced feedback regarding message transmission and recipient interaction.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted on 04/27/2026 with respect to the rejection of the claims have been carefully considered and is addressed below.
Double Patenting
The nonstatutory obvious type double patenting rejection is withdrawn in view of terminal disclaimer filed on 4/27/2026.
Claim Rejections - 35 USC § 101
Applicant argues that claim 1 is patent eligible because it recites executing a messaging protocol using hardware processors, network nodes, and a message protocol table, and therefore allegedly cannot be performed in the human mind. This argument is not persuasive. The Examiner has not asserted that every claimed limitation, including the generic computer components, can literally be performed mentally. Instead, the claim recites a mental process because it includes the steps of receiving a messaging request, comparing routing information with stored routing information, determining whether a destination can be identified, deciding whether to send the message or forward the request, and identifying an intended recipient. These are observations, evaluations, judgments, and decisions that, under their broadest reasonable interpretation, can practically be performed in the human mind or with the aid of pen and paper. The additional recitation of generic processors, network nodes, and electronic communications merely identifies the technological tools used to implement the abstract idea and does not remove the claim from the mental process grouping.
Applicant further states that the claims improve electronic communications by organizing the activities of electronic components rather than human activities. However, the claims do not recite any specific improvement to computer functionality, network communications, or message routing technology. Although claim 1 recites a first node, a second node, and a network, these elements are recited at a high level of generality and merely provide a generic computing environment in which the abstract idea is performed. The claim does not recite any improvement to routing tables, any modification to network architecture, or any technological improvement in the operation of processors, nodes, or communication networks. Instead, the claim broadly recites determining whether an endpoint can be identified and either sending the message or forwarding the request based on that determination. Accordingly, the claim uses generic computer technology as a tool to perform the abstract idea rather than improving the functioning of the computer or another technology.
Applicant also states that the additional claim elements integrate any alleged abstract idea into a practical application because the claims recite transmitting messages between network nodes within a communication architecture. This argument is not persuasive. The additional elements implement the abstract idea in the context of a particular technological environment, specifically a network associated with a medical environment, and therefore amount to no more than generally linking the judicial exception to a particular technological field. Also, the limitations directed to detecting a request, generating a transmission, and electronically communicating the transmission gather information before performing the abstract analysis and communicate the results afterward, which constitute insignificant extra-solution activities. These limitations do not impose a meaningful limit on the judicial exception and therefore do not integrate the abstract idea into a practical application under Step 2A, Prong Two.
Lastly, Applicant states that the claims provide an inventive concept under Step 2B. However, the additional elements, considered individually and as an ordered combination, invoke generic processors, network nodes, and electronic communications performing their conventional functions of receiving, processing, routing, and transmitting information. These generic computer components do not improve the functioning of the computer itself or another technology, however instead simply automate the abstract process of evaluating routing information and determining how a message should be routed. Therefore, the additional elements do not amount to significantly more than the judicial exception and the rejection under 35 U.S.C. 101 is maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments traversing the prior art rejection in the previous Office Action have been fully considered. However, those arguments are rendered moot because the present rejection under 35 U.S.C. §103 relies on a different set of prior art references (Hartman, Dorsey, and Rybkin), which teach or suggest the limitations of the claims. Accordingly, Applicant’s prior arguments are not responsive to the current grounds of rejection. The rejection of claims 1-4, and 6-21 under 35 U.S.C. §103 is therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure.
Wang et al. (U.S. Patent Publication 2012/0136995 A1) teaches a process that monitors IP flow data to detect when an application server becomes unavailable, identifies affected active users through their IP addresses, and notifies them, then later alerts them again when the server becomes available.
Fernandez et al. (U.S. Patent Publication 2013/0232209 A1) teaches a method and system for managing communications by storing permitted user relationships in a name directory and periodically transmitting that directory to authorized users via a messaging server.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights