DETAILED CORRESPONDENCE
This is a non-final office action on merits in response to the arguments and/or amendments filed on 1/21/2026 and the request for continued examination filed on 1/21/2026.
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
Claims 21-23 are new. Claims 7, 14, and 20 are cancelled. Amendments to claims 1, 2, 6, 8, 9, 13, 15, 16, and 18 are acknowledged and have been carefully considered. Claims 1-6, 8-13, 15-19 and 21-23 are pending and considered below.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/21/2026 has been entered.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8, and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 9, and 14 of U.S. Patent No. 10453565 B2 (’565 patent).
Claim 1 is rejected because the ’565 patent teaches a computer-implemented method for transmitting clinically relevant messages across domains using indirect addressing in which a target endpoint address is initially unknown and resolving the destination via a role to identify an intended target for message delivery. Specifically, the ’565 patent discloses detecting a request to transmit a message including clinically relevant information from electronic medical records to a destination in a separate domain where the target endpoint address is unknown, determining that the destination is associated with a role, identifying an intended target associated with the role, generating a transmission for the intended target, and communicating the transmission, as well as dynamically modifying the transmission based on changes to the clinical information (see claim 9).
Similarly, the present claim 1 recites detecting a request to transmit a message including clinical information from electronic medical records across domains, identifying a preferred path to a target endpoint address, determining that the preferred path is unavailable, identifying an alternate path, and transmitting a corresponding notification to the target endpoint address. These limitations correspond to the messaging functionality disclosed in the ’565 patent in which messages are routed to intended targets across domains using indirect addressing and are dynamically handled based on system conditions affecting delivery or content.
The additional limitations of claim 1 directed to identifying a preferred path and, upon determining that the preferred path is unavailable, transmitting a notification excluding the clinical information via an alternate path would have been obvious to incorporate into the messaging system of the ’565 patent in order to improve delivery reliability and protect sensitive clinical data during transmission when primary delivery mechanisms fail. These fallback routing and selective transmission of message content constitutes a predictable implementation of known messaging system features and does not render the claimed invention patentably distinct from the subject matter claimed in the ’565 patent.
Claims 8 and 15 are rejected under the doctrine of nonstatutory obviousness-type double patenting for the same reasons set forth with respect to claim 1. Claims 8 and 15 recite substantially the same limitations as claim 1 but are presented in different statutory classes, as a system and one or more non-transitory media having computer-readable instructions, respectively. Specifically, claims 8 and 15 similarly recite detecting a request to transmit a message including particular clinical information identified from one or more electronic medical records to a destination in a separate domain, determining that a preferred path to a target endpoint address is unavailable, identifying an alternate path, generating a notification corresponding to the message that excludes the clinical information, and transmitting the notification via the alternate path to the target endpoint address. These limitations correspond to the messaging functionality disclosed in claim 9 of the ’565 patent and differ only in the recitation of the invention in a different statutory form. Accordingly, claims 8 and 15 are not patentably distinct from the subject matter claimed in the ’565 patent for the reasons discussed above.
Claim Rejections - 35 USC § 112
Claims 3, 4, and 5 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 3 recites that “the target endpoint address includes at least one of a phone number or an email address.” However, the specification only discloses endpoint addresses in the form of protocol identifiers, such as “user@domain,” “group@domain,” or “service@domain”, and does not describe or suggest that endpoint addresses include phone numbers or email addresses. Accordingly, the specification does not reasonably convey possession of this limitation. The claim further recites that “the notification comprises a selectable acknowledgement request” and “receiving an indication that the selectable acknowledgement request has been selected.” The specification describes device level acknowledgements and user-level acknowledgements (read receipts) that are automatically generated and received by the system. However, the specification does not describe a selectable acknowledgement request, user interaction for selecting such a request, or receiving an indication based on such a selection. The disclosed acknowledgements are system generated delivery and read confirmations, not selectable acknowledgement requests.
Claim 4 recites “detecting a user device within a physical proximity of one of the physical locations.” While the specification describes domains associated with physically distinct locations and further describes recognizing or detecting a user or user device at an associated location, the specification does not describe detecting a user device based on physical proximity to a location. The disclosed embodiments describe recognizing presence of a user or device at a location or within a system, but do not describe or suggest determining proximity (based on distance or relative positioning) of a user device to a physical location. Accordingly, the specification does not reasonably convey possession of detecting a user device within a physical proximity of a physical location.
Claim 5 recites “linking the target device to a role…based on the physical proximity.” While the specification describes dynamically assigning users to roles or groups based on location or presence, such as adding a user to a group upon entering a particular hospital area, the specification does not describe or suggest linking a device to a role based on physical proximity. The disclosed embodiments describe role or group assignment based on presence at a location, but do not describe determining proximity (based on distance or relative positioning) of a user device to a location as a basis for role assignment. Accordingly, the specification does not reasonably convey possession of linking a target device to a role based on physical proximity.
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-6, 8-13, 15-19 and 21-23 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-6 are drawn to a method, and claims 8-13 are drawn to a system, and claims 15-19, and 21-23 are drawn to one or more non-transitory media. 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 identifying a first path, for transmitting the message to a target endpoint address associated with the target device, as a preferred path; determining that the first path to the target endpoint address is unavailable; and in response to determining that the first path to the target endpoint address is unavailable: (a) identifying, a second path to the target endpoint address via the service. 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 “via the one or more hardware processors and via the service” language, the claim encompasses a user evaluating available communication routes, determining whether a preferred route is unavailable, and selecting an alternative route for message delievery in their mind or by using a pen and paper. The mere nominal recitations of via the one or more hardware processors and via the service do not take the claim limitations out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
Claim 1 also recites as a whole a method of organizing human activity (i.e., 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 detect a request from a source device to transmit a message via the service to a group, wherein: the group includes a destination associated with a target device, the message includes a payload comprising particular clinical information identified from one or more electronic medical records, and the control server and the destination are in separate domains associated with the medical environment; generate a notification that corresponds to the message and that does not include the particular clinical information; and transmitting the notification to the target endpoint address via the second path, wherein the notification is transmitted to the target endpoint address via the second path without the particular clinical information. This is a method of managing communication and interactions between individuals by apply rules for routing messages and selectively modifying message content based on delivery conditions. The mere nominal recitation of a generic via the one or more hardware processors at the control server and via the service does not take the claim out of the certain methods of organizing human activity. Thus, the claim recites an abstract idea.
The types of identified abstract ideas are considered together as a single abstract idea for analysis purposes.
Independent claim 8 and 15 recites identical or nearly identical steps with respect to claim 1 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per method claim 1, include the steps of:
executing a messaging protocol via the one or more hardware processors, wherein executing the messaging protocol is performed at a control server (i) comprising a JavaScript Object Notation (JSON) serialized transport and an application layer protocol specifying JSON serialization, (ii) associated with a medical environment, (iii) utilizing a websocket protocol layer above a Transmission Control Protocol (TCP) layer, and (iv) providing messaging between an endpoint and a service;
detecting, via the one or more hardware processors at the control server, a request from a source device to transmit a message via the service to a group, wherein:the group includes a destination associated with a target device, the message includes a payload comprising particular clinical information identified from one or more electronic medical records, and the control server and the destination are in separate domains associated with the medical environment;
identifying a first path, for transmitting the message via the service to a target endpoint address associated with the target device, as a preferred path;
determining that the first path to the target endpoint address is unavailable; and in response to determining that the first path to the target endpoint address is unavailable:
(a) identifying, via the one or more hardware processors, a second path to the target endpoint address via the service;
(b) generating a notification that corresponds to the message and that does not include the particular clinical information; and
(c) transmitting the notification via the service to the target endpoint address via the second path, wherein the notification is transmitted to the target endpoint address via the second path without the particular clinical information.
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 and message routing between participants based on conditions, including delivery paths and modifying message content in a computer environment. The claimed computer components (i.e., executing a messaging protocol via the one or more hardware processors, wherein executing the messaging protocol is performed at a control server (i) comprising a JavaScript Object Notation (JSON) serialized transport and an application layer protocol specifying JSON serialization, (iii) utilizing a websocket protocol layer above a Transmission Control Protocol (TCP) layer, and (iv) providing messaging between an endpoint and a service; via the one or more hardware processors at the control server; via the service; and via the one or more hardware processors) are recited at a high level of generality and are merely invoked as tools to perform an existing process of routing and managing communications between users according to predefined rules. 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., medical messaging environment involving transmission of clinical information across domains), 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 element that is carried out in a technical environment includes “at a control sever…associated with a medical environment”. Accordingly, alone and in combination, this additional element does not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of managing communication and message routing between participants based on conditions, including delivery paths and modifying message content 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 4-6, 11-13, 18-19, and 21-23 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-3, 9-10, and 16-17 recite the additional elements of displaying a notification regarding the communicating on the target device (claims 2, 9, and 16), receiving an indication that the selectable acknowledgement request has been selected (claim 3, 10, and 17). However, these additional elements amount to mere data gathering and displaying a result (i.e., an insignificant extra-solution activity)). As such, these additional elements, when considered individually or in combination, 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-5, 8-12, 15-17, 19, and 21-23 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 Gangadharan et al. (U.S. Patent Publication 2014/0222930 A1), referred to hereinafter as Gangadharan, 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 performed by one or more hardware processors, the computer-implemented method comprising (Rybkin [0004] “The method may be implemented by a computer system including computer hardware.”):
executing a messaging protocol via the one or more hardware processors, wherein executing the messaging protocol is performed at a control server (Rybkin [0006] “In several embodiments, non-transitory physical computer storage can include instructions stored thereon that, when executed by one or more processors, cause the one or more processors to implement a system for making patient care messages available to healthcare providers on different shifts. The system can include: a messaging component that can: electronically generate a patient messaging user interface; provide a first team of healthcare providers with access to the patient messaging user interface while the first team of healthcare providers is assigned to care for the patient, where the patient messaging user interface can enable the first team of healthcare providers to post messages regarding care of the patient for access by each member of the first team of healthcare providers and by the second team of healthcare providers, without the first team of healthcare providers having to know an identity of the second team of healthcare providers when posting the messages; and automatically provide the second team of healthcare providers with access to the posted message regarding the patient posted by the first team of healthcare providers in response to care of the patient being transferred from the first team of healthcare providers to the second team of healthcare providers.”, and Rybkin [0020] “The aggregator 120 can include software that executes on one or more computing devices, such as one or more physical server computers. In embodiments where the aggregator 120 is implemented on multiple servers, these servers can be co-located or can be geographically separate (such as in separate data centers). In addition, the aggregator 120 can be implemented in a cloud computing platform, such as may be available from Amazon Web Services™, the Windows Azure™ Platform, or the like. For instance, the aggregator 120 can be implemented in one or more virtual machines that execute on one or more physical servers. Further, the aggregator 120 can include a server or appliance on the local area network, which is protected from the wide area network (e.g., the public Internet or other network) by a firewall or other security mechanism.”);
(ii) associated with a medical environment (Rybkin [0073] “The aggregator 120 can be implemented in the cloud, or more generally, in one or more servers or other computing devices accessible by clinicians both inside and outside of the hospital to facilitate this continuum of care functionality.”),
(iv) providing messaging between an endpoint and a service (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 [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).”),
detecting, via the one or more hardware processors at the control server, a request from a source device to transmit a message via the service to a group wherein:the group includes a destination associated with a target device (Rybkin [0021] “In several embodiments, the handoff component 122 of the aggregator 120 can allow providers to sign out or handoff patient care to one another at shift changes (or at other times). This handoff process can symbolically represent the transfer of responsibility for the care of a patient. The messaging component 126 can provide functionality for providers to send messages to one another and to subsequent providers on different shifts, without having to know the identity of these providers beforehand. The compliance component 126 can provide functionality for a clinical facility to comply with regulations related to patient care, such as regulations regarding working hours of medical trainees like interns and residents. It should be understood that any handoff functionality described herein can be implemented by the handoff component 122, any messaging functionality described herein can be implemented by the messaging component 124, and any compliance functionality described herein can be implemented by the compliance component 126. Any subset of the features described herein with respect to the aggregator 120 may be implemented in any given embodiment.”, 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 [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.”),
the message includes a payload comprising particular clinical information identified from one or more electronic medical records, and the control server and the destination are in separate domains associated with the medical environment (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).” 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.”).
identifying a first path, for transmitting the message via the service to a target endpoint address associated with the target device (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 [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).”);
determining that the first path to the target endpoint address is unavailable; and in response to determining that the first path to the target endpoint address is unavailable: (a) identifying, via the one or more hardware processors, a second path to the target endpoint address via the service (Kim, Col. 21, lines 10-67 and Col. 22, lines 1-19 “In at least one of the various embodiments, the message providers associated with a region may be distinguishable in terms of reliability, cost, quality-of-service, or the like, or combination thereof. Accordingly, in at least one of the various embodiments, each message provider associated with a region may be associated with a proportional weighting value. The weighting value may be employed to drive notification message to use the most desirable message provider, if there is one. For example, according to table 512, for region 506 message provider “X1” is more desirable than message provider “X3”. Also in this example, according to table 514, for region 510 message provider “A1” is preferred over message provider “A3. 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.”);
Rybkin fails to explicitly teach (i) comprising a JavaScript Object Notation (JSON) serialized transport and an application layer protocol specifying JSON serialization;
(iii) utilizing a websocket protocol layer above a Transmission Control Protocol (TCP) layer;
as a preferred path; and
(b) generating a notification that corresponds to the message and that does not include the particular clinical information; and (c) transmitting the notification via the service to the target endpoint address via the second path, wherein the notification is transmitted to the target endpoint address via the second path without the particular clinical information.
Gangadharan teaches (i) comprising a JavaScript Object Notation (JSON) serialized transport and an application layer protocol specifying JSON serialization ((Gangadharan [0025] “In a particular embodiment, the protocol of the present invention provides part of a system and method for exchanging signaling messages between HTML5 applications and a network-side controller, for example Oracle™ WebRTC Session Controller (WSC). The protocol is based in part on JavaScript Object Notation (JSON) and, thus, leverages JSON objects commonly used by HTML5 applications to specify a message format, data exchange protocol, and reliability protocol. The protocol utilizes WebSocket and the protocol can be used on multiple transports (COMET, BOSH, and WebSocket). The JSON-based protocol, which can be called a JSONrtc protocol, can be used by a network-side controller to mediate real-time communications between HTML5 applications and non-HTML5 endpoints. The protocol and message format is friendly for conversion to other protocols used by non-HTML5 environments, thus enabling the signaling sever to mediate between an HTML5 application and a non-HTML5 endpoint, e.g., traditional telephony equipment.”).
(iii) utilizing a websocket protocol layer above a Transmission Control Protocol (TCP) layer ((Gangadharan [0025] “In a particular embodiment, the protocol of the present invention provides part of a system and method for exchanging signaling messages between HTML5 applications and a network-side controller, for example Oracle™ WebRTC Session Controller (WSC). The protocol is based in part on JavaScript Object Notation (JSON) and, thus, leverages JSON objects commonly used by HTML5 applications to specify a message format, data exchange protocol, and reliability protocol. The protocol utilizes WebSocket and the protocol can be used on multiple transports (COMET, BOSH, and WebSocket). The JSON-based protocol, which can be called a JSONrtc protocol, can be used by a network-side controller to mediate real-time communications between HTML5 applications and non-HTML5 endpoints. The protocol and message format is friendly for conversion to other protocols used by non-HTML5 environments, thus enabling the signaling sever to mediate between an HTML5 application and a non-HTML5 endpoint, e.g., traditional telephony equipment.”),
Kim teaches as a preferred path (Kim, Col. 29, lines 31-48, “At block 714, in at least one of the various embodiments, the notification engine may employ various methods to determine and/or select a message provider from the list of available providers. As discussed above, the notification engine may employ proportional distribution, or the like. In at least one of the various embodiments, each message provider may be associated with additional information that may be employed for determining if it may be selected for routing a message. This information may include weighting and/or preference information as well as raw and/or aggregated performance metrics that may have been collected.”);
(b) generating a notification that corresponds to the message and that does not include the particular clinical information; and via the second path without the particular clinical information (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.” Kim, Col. 25, lines 53-65, “At block 610, in at least one of the various embodiments, a notification message may be provided to the determined responsible resource using the determined message provider. The notification engine may send one or more notification message to alert the responsible resources of the event message so they can take appropriate actions. In at least one of the various embodiments, notification messages may take a variety of forms/formats depending on the preferences of the responsible resources and the capabilities of the message providers. For example, in at least one of the various embodiments, notification messages may be provided using SMS texts, email, mobile device push notifications, HTTP requests, voice calls, library function calls, audio alerts, haptic alert, or the like, or combination thereof.”);
Underwood teaches (c) transmitting the notification via the service to the target endpoint address via the second path, wherein the notification is transmitted to the target endpoint address (Underwood [0048] “As shown in FIG. 2, originating device 101 forwards the IM message 201 to the delivery server 105 for delivery to the recipient device 107 via the primary deliver channel 202. The delivery server 105 sends an acknowledgement message back to the originating device 101. The delivery server on-sends the IM message to the recipient device 107. The recipient device 107 then sends back an acknowledgement message 203 to the delivery server 105, the delivery server 105 then optionally advises the sending device 101 of successful end-to-end delivery of the message 204. In the event that the primary delivery 202 channel is unavailable delivery server 105 then attempts to route the message via an alternate delivery channel such as email 205 via email gateway 108, or SMS 206 via SMSC 109.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the healthcare messaging system of Rybkin to incorporate known communication protocol and routing techniques to improve the reliability, and efficiency of message delivery in a distributed medical environment. Rybkin teaches a computer implemented system that facilitates transmission of messages containing clinical information derived from electronic medical records and dynamically routes such messages to appropriate providers based on team associations and provider status. Rybkin further teaches operation across multiple systems and healthcare facilities, thereby supporting messaging between endpoints and services in a medical environment. However, Rybkin does not explicitly disclose particular message transport formats such as JSON over WebSocket/TCP or the use of fallback communication paths when a preferred transmission path is unavailable.
Gangadharan teaches a messaging protocol based on JavaScript Object Notation (JSON) and operating over a WebSocket layer above a Transmission Control Protocol (TCP) layer, enabling real time communication between endpoints and services. These features provide standardized and efficient message transport across systems. A person of ordinary skill in the art would have been motivated to incorporate such known communication protocols into Rybkin’s system in order to improve compatibility between devices and services, enhance real time communication capabilities, and streamline data exchange in a healthcare messaging environment.
Kim teaches selecting among multiple message providers based on performance characteristics such as reliability, cost, and quality of service, and further teaches identifying alternate providers when a preferred communication path is unavailable. This enables dynamic rerouting of messages and improves system fault tolerance. A person of ordinary skill in the art would have recognized that incorporating such dynamic path selection and fallback routing into Rybkin’s system would improve reliability of message delivery, especially in time sensitive healthcare contexts where uninterrupted communication is critical.
Underwood teaches transmitting notifications and rerouting messages through alternate delivery channels when a primary communication path is unavailable, including sending notifications that may omit full message content and instead alert a recipient to access the message through another channel. A person of ordinary skill in the art would have been motivated to incorporate these techniques into Rybkin’s system to reduce transmission overhead and ensure timely notification even when full message delivery is not immediately possible. Accordingly, the combination of Rybkin with Gangadharan, Kim, and Underwood represents the predictable use of known communication and routing techniques to improve a healthcare messaging system, yielding no more than the expected results of enhanced efficiency and reliability and therefore does not render the claimed invention patentably distinct.
Regarding claim 2, Rybkin, Gangadharan, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach further comprising communicating the message to the destination and displaying a notification regarding the communicating on the target device (Rybkin [0033] At block 356, the messaging component 124 determines a team associated with the patient by consulting a patient-team association table 355 or the like. Once the team is identified, the messaging component 124 can determine which doctors are associated with that team at block 357 by accessing a doctor-team association table 358 or the like. The messaging component 124 then determines whether a given one of those doctors is currently on duty at decision block 360. (The process of picking a particular doctor to contact from a team of doctors is described in greater detail below.) The messaging component 124 can determine this doctor status information by consulting the status monitor database 359. If the relevant doctor from the team is currently on duty, the messaging component 124 delivers the message to the doctor at block 362. The message can be delivered via pager 364, secure (or other) mobile communications 366, via a doctor dashboard 368 or similar display (see below), or the like. If the doctor is not available, the messaging component 124 can determine whether another doctor in the team is available, repeating blocks 360 through 362.” and
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 having ordinary skill in the art at the time of the invention to modify Rybkin’s healthcare messaging system to include displaying a notification regarding message communication as taught by Underwood. Rybkin teaches transmitting clinical messages to appropriate providers across computing devices within a medical environment, including delivery of messages to target devices such as mobile devices and dashboards. Underwood teaches generating and transmitting acknowledgement notifications to devices indicating successful delivery of messages. A person of ordinary skill in the art would have been motivated to incorporate Underwood’s acknowledgement and notification mechanisms into Rybkin’s messaging system in order to inform users of message delivery status and enhance user awareness in time sensitive clinical environments. The combination applies known notification and acknowledgement techniques to an existing messaging system to yield predictable results, specifically providing confirmation and visibility of message transmission events, and therefore represents no more than the predictable use of prior art elements according to their established functions.
Regarding claim 3, Rybkin, Gangadharan, Kim, and Underwood teach the invention in claim 2, as discussed above, and further teach wherein the target endpoint address includes at least one of a phone number or an email address, wherein the notification comprises a selectable acknowledgement request, and further comprising receiving an indication that the selectable acknowledgement request has been selected (Rybkin [0047] “The message user interface 700 also contains a select box control 712 that enables optionally paging the recipients presently or at some time in the future. If this control 712 is chosen, the aggregator 120 connects to the paging provider 180 (FIG. 1) and places a page electronically. The messages sent through the non-secure paging system may include the notifications that a message is available to be viewed, and the user may log in to the secure portal to view it. Alternatively, the aggregator 120 may have the capability to send messages through other means, such as email or Short Messaging Service (SMS) through secure or non-secure means (e.g., block 170 of FIG. 1). The aggregator 120 may also publish an Application Programming Interface (API), through which an (optionally secure) client application may connect and receive messages or notifications (example client applications are described below).” and
Kim, “In at least one of the various embodiments, scheduler 402 may determine which resource is responsible for handling the event message based on at least an on-call schedule and/or the content of the event message. Next, notification engine 406 may generate one or more notification messages and determine a particular message providers to use to send the notification message. Accordingly, the selected message providers, such as, message provider 416, message provider 418, or message provider 420, may communicate the notification message to the responsible resource perhaps by sending it mobile computer 422. In some embodiments, the message providers may generate an acknowledgment message that may be provided to system 400 that indicates delivery of the notification message.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the messaging system of Rybkin in view of Kim to include a notification comprising a selectable acknowledgement request and to receive an indication that the acknowledgement has been selected. Rybkin teaches transmitting notifications related to messages via various communication channels, including email and SMS, and further teaches user interface elements that allow users to select messaging actions (select box controls for paging and communication). Kim teaches generating notification messages and providing acknowledgement messages indicating delivery of those notifications. A person of ordinary skill in the art would have been motivated to incorporate Kim’s acknowledgement functionality into Rybkin’s messaging system and further adapt the user interface of Rybkin to allow a user selectable acknowledgement mechanism, in order to improve message tracking, confirmation of receipt, and overall communication reliability. This modification represents a predictable use of known notification and acknowledgement techniques within a messaging system and would have yielded no more than the expected result of enhanced user interaction and delivery confirmation.
Regarding claim 4, Rybkin, Gangadharan, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein the separate domains are associated with differing physical locations, and further comprising detecting a user device within a physical proximity of one of the physical locations (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 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 [0036] “Once the provider is logged in, he may be presented with a user interface 400A shown in FIG. 4A. In this user interface 400A, a button (or other control) 410 is shown, which is selectable by the provider to enable starting his shift. Alternatively, the aggregator 120 may include a facility to start the provider's shift by detecting the presence of the provider by recognizing a biometric key, an access card, a hardware security token (such as a fob), by proximity detection technology (such as RFID), any other available authentication technology, combinations of the same, or the like. The aggregator 120 may also include additional controls, centralized in a scalable “cloud” infrastructure, leveraging efficiencies of scale and minimizing cost which would allow the provider to identify nuances of his status, for example, the provider may have ended his in-hospital shift, but remains on pager call from home.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the messaging system of Rybkin to include detecting a user device within a physical proximity of a physical location in a multi-domain healthcare environment. Rybkin teaches a distributed healthcare messaging system operating across multiple clinical facilities and domains (hospitals, clinics, and other care settings) connected via network infrastructure, which corresponding to separate domains associated with differing physical locations. Rybkin further teaches detecting the presence of a provider using proximity technologies such as RFID, biometric authentication, or access tokens, which enables the system to determine when a user is physically present at a given location. A person of ordinary skill in the art would have recognized that detecting a provider’s presence using proximity detection implicitly involves detecting the provider’s associated device or system session within that location. Accordingly, it would have been obvious to incorporate such proximity detection mechanisms into Rybkin’s multi-domain messaging system in order to improve routing accuracy and enhance real time communication reliability in healthcare environments. This modification represents a predictable use of known presence detection techniques to improve the performance of distributed messaging systems and does not render the claimed invention patentably distinct.
Regarding claim 5, Rybkin, Gangadharan, Kim, and Underwood teach the invention in claim 4, as discussed above, and further teach further comprising: linking the target device to a role, associated with the destination, based on the physical proximity; and transmitting the message to the target device linked to the role (Rybkin [0045] “More generally, a first role can be assigned to respond to a message or task first, and a second role can be assigned to respond to the message subsequent to the first role, and so on up to as many people are included in a team. The messaging user interface 700 can provide functionality to prioritize messages or tasks in this manner. As an illustration, a first role can be a training role such as an intern or resident, while the second role can be a supervisory role such as a resident (for supervising an intern) and an attending physician. The messaging user interface 700 can allow the order of roles to be notified to be selected without selecting actual names of providers. In response to a patient being handed off to a new healthcare team, the aggregator 120 can determine the roles of the providers in the new healthcare team and send messages (at the proper time) to such providers accordingly.”, Rybkin [0036] “Once the provider is logged in, he may be presented with a user interface 400A shown in FIG. 4A. In this user interface 400A, a button (or other control) 410 is shown, which is selectable by the provider to enable starting his shift. Alternatively, the aggregator 120 may include a facility to start the provider's shift by detecting the presence of the provider by recognizing a biometric key, an access card, a hardware security token (such as a fob), by proximity detection technology (such as RFID), any other available authentication technology, combinations of the same, or the like. The aggregator 120 may also include additional controls, centralized in a scalable “cloud” infrastructure, leveraging efficiencies of scale and minimizing cost which would allow the provider to identify nuances of his status, for example, the provider may have ended his in-hospital shift, but remains on pager call from home.”).,” 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 system of Rybkin to link a target device to a role based on physical proximity. Rybkin teaches routing messages based on roles associated with healthcare providers rather than specific identities and further teaches dynamically determining which provider is responsible for a patient by consulting team associations and identifying which provider is currently on duty. Rybkin also teaches detecting the presence of a provider using proximity technologies such as RFID, biometric authentication, or access tokens, thereby enabling the system to determine when a provider is physically present at a particular location. A person of ordinary skill in the art would have recognized that provider presence and on duty status are implicitly tied to role responsibilities within a healthcare environment, and that combining proximity presence detection with dynamic role assignment would allow the system to automatically associate a provider’s device with an appropriate role at a given location. Accordingly, it would have been obvious to integrate Rybkin’s proximity detection mechanisms with its role and dynamically assigned messaging framework to link target devices to roles based on physical proximity and transmit messages accordingly. Such a modification represents a predictable use of known techniques to improve message routing accuracy and ensure delivery to the appropriate on site personnel, and therefore does not render the claimed invention patentably distinct.
Claims 8-12 are analogous to claims 1-5, thus claims 8-12 are similarly analyzed and rejected in a manner consistent with the rejection of claims 1-5.
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 19 is analogous to claim 5, thus claim 19 is similarly analyzed and rejected in a manner consistent with the rejection of claim 5.
Regarding claim 21, Rybkin, Gangadharan, Kim, and Underwood teach the invention in claim 15, as discussed above, and further teach wherein the particular clinical information comprises a message payload selected from a group comprising a video file, an image file, and a file containing a wave form (Rybkin [0079] The aggregator 120, including messages, information user interfaces and grids, as well as team management functions, can be accessed with standard web browsers on the healthcare facility's local area network. Users may access the aggregator 120 from the computers directly connected to the LAN or from the mobile devices that securely connect to the facility wireless network (Wi-Fi). Alternatively, the aggregator 120 may publish an Application Programming Interface (API), which would allow appropriately credentialed and provisioned devices and application to access the aggregator 120's information. A possible embodiment of such client application is a native program on a mobile device, which accesses the aggregator 120 through a defined web service address, presenting appropriate security credentials. The client application can use appropriate protocols (such as SOAP or REST) to exchange information with the aggregator 120, allowing users immediate real-time (or rapid) access to the flow of messages. Further, the routing capability of the aggregator 120 can be used to initiate IP-based voice communication. For example, a provider may send a specialized message (dynamically routed in the standard fashion) to a mobile device. The provider with the device immediately initiates a VoIP connection with the sender of the message. Moreover, messages can have the capability to optionally attach other documents, such as photographs, radiological images, textual and/or multimedia documents to the body of the message. Other forms of communications, such as links to other online media or voice/video recordings could likewise be embedded.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the messaging system of Rybkin to include a message payload comprising multimedia clinical information such as video files, image files, and waveform files. Rybkin teaches a healthcare messaging system in which messages may include attachments such as photographs, radiological images, multimedia documents, and voice or video recordings. These disclosures demonstrate that clinical information may be transmitted as various types of media content, including visual and audio data. A person of ordinary skill in the art would have recognized that such multimedia attachments implicitly include commonly used file types such as image files (photographs, radiological images), video files, and audio recordings (which are waveform data), and that selecting among these known formats for inclusion in a message payload would have been a routine design choice. Accordingly, implementing the claimed selection of a message payload from a group including video, image, and waveform files represents no more than the predictable use of known messaging content types within a healthcare communication system and does not render the claimed invention patentably distinct.
Claims 22-23 are analogous to claim 21, thus claims 22-23 are similarly analyzed and rejected in a manner consistent with the rejection of claim 21.
Claims 6, 13, and 18 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 Gangadharan et al. (U.S. Patent Publication 2014/0222930 A1), referred to hereinafter as Gangadharan, 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, further in view of Bao et al. (JP Publication No. JP 2004199663 A).
Regarding claim 6, Rybkin, Gangadharan, Kim, and Underwood teach the invention in claim 1, as discussed above, and further teach wherein the destination corresponds to a set of individuals associated with the sub-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.”).
Rybkin, Gangadharan, Kim, and Underwood fail to explicitly teach , wherein the separate domains include: a parent domain; and a sub-domain associated with a domain lookup table.
Bao teaches wherein the separate domains include: a parent domain; and a sub-domain associated with a domain lookup table (Bao, [0006] “Referring to the drawings, FIG. 1 is a block diagram of a patient identification model in a database. The patient entity (P) models a real patient. Patient identification information (PID) 110 models the actual patient ID data input, including attributes assigned to patient (P). Such attributes include, but are not limited to, patient name, patient age, patient social security number, patient gender, patient address, or other information as selected by the user and available in the system 10. It can be. The PID 110 can also be a number assigned by a particular patient registration service. Each issuer of PID 110 is modeled as a patient identification domain entity (PIDD). PIDD 22 models a real domain where all PIDs are issued from the same system in a consistent manner.”, and Bao [0007] “The health management company 20 can be assigned a unique identification number (PIDD-ID) 24. In such a health management company 20, a default PIDD 22 is assigned to each facility 12, and a default PIDD 22 is also assigned to each department 14 and equipment 16 used in the department of the facility 12. Each such entity is assigned a separate default PIDD, and each PIDD 22 is associated with a PIDD-ID 24 in the system 10. Each PID 110 and PIDD 22 are concatenated to form a unique patient identification number 112 within the health care company 20. The various PID, PIDD, default PIDD and PIDD-ID values are stored in a lookup table 108 maintained on the storage device 106 in the system 10 or attached to the system 10.”).
It would have been obvious to a person having ordinary skill in the art at the time of the invention to modify Rybkin’s healthcare messaging system to incorporate the hierarchical domain structure and lookup table mechanisms taught by Bao in order to improve organization and routing of messages across multiple entities within a medical environment. Bao teaches a domaim architecture in which a healthcare enterprise includes multiple hierarchical levels such as facilities, departments, and equipment, each associated with a domain identifier (PIDD), thereby corresponding to parent and sub-domain relationships, and further teaches storing these domain associations in a lookup table to enable efficient identification and resolution of entities. Rybkin teaches directing messages to a team of providers associated with a patient, where the system determines a set of individuals forming the destination for the message and delivers the message accordingly. A person of ordinary skill in the art would have been motivated to organize Rybkin’s group messaging using Bao’s hierarchical domain structure and lookup table in order to facilitate scalable management of users and improve the efficiency of identifying and routing messages to appropriate groups of individuals across different organizational units. The combination applies known hierarchical data organization and lookup techniques to an existing messaging system to yield predictable results, specifically structured domain routing to sets of individuals, and therefore represents no more than the predictable use of prior art elements according to their established functions.
Claim 13 is analogous to claim 6, thus claim 13 is similarly analyzed and rejected in a manner consistent with the rejection of claim 6.
Claim 18 is analogous to claims 4 and 6, thus claim 18 is similarly analyzed and rejected in a manner consistent with the rejection of claims 4 and 6.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted 1/21/2026 with respect to the rejection of claims 1-6, 8-13, 15-19 and 21-23 have been carefully considered and are addressed below.
Claim Rejections - 35 USC § 101
Applicant’s amendments and arguments have been fully considered but are not persuasive. Claim 1 is directed to an abstract idea. Specifically, the claim recites a method of managing the transmission of messages by determining a preferred path, evaluating whether that path is available, selecting an alternate path when necessary, and modifying the content of the communication (generating a notification without the clinical payload) based on delivery conditions. These limitations constitute certain methods of organizing human activity, specifically managing communication and interactions between participants, as well as mental processes involving evaluation, judgment, and decision making steps that can be performed conceptually.
Applicant states that the claim cannot be performed mentally because it recites hardware processors, a control server, and specific communication protocols is not persuasive. The analysis considers whether the claimed concept itself, apart from generic computer implementation, can be performed mentally. In this claim, the underlying concept of selecting a communication path, determining availability, and sending a modified message based on that determination can be carried out by a human using conventional communication tools. The recitation of generic computing components does not remove the claim from the mental process category.
Applicant further argues that the claim does not involve organizing human activity because it does not explicitly recite humans. This argument is also unpersuasive. The claim is directed to managing communication between endpoints associated with users in a medical environment, which implicitly involves interactions between people. The fact that these interactions are implemented through devices does not negate that the claim governs how communications are routed and delivered between participants. Therefore, the claim falls within the category of certain methods of organizing human activity.
With respect to Step 2A, Prong Two, the additional elements do not integrate the abstract idea into a practical application. The recited control server, JSON serialization, WebSocket protocol, and TCP layer represent conventional computing and networking technologies. These elements merely provide an environment in which the abstract idea is carried out and do not improve the functioning of the computer itself or any other technology. The claimed “notification without payload” represents a data handling choice rather than a technical improvement to network operations or protocol.
Lastly, applicant’s statement of a technical improvement is not supported by the claim. The alleged benefit of reducing message size or modifying transmitted content does not reflect an improvement to computer technology, but rather a business or policy decision regarding what information to transmit under certain conditions. The claim does not recite any specific mechanism that improves data transmission efficiency at a technical level, for example as improvements to bandwidth utilization or data encoding techniques. Accordingly, 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 (Rybkin, Gangadharan, Kim, Underwood, and Bao), 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-5, 8-12, 15-17, 19, and 21-23 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.
Shurtz (U.S. Patent Publication 2016/0379470 ) teaches a system that detects a failed emergency call to a PSAP, prompts the caller for situational information, and generates and forwards a message containing location and priority data to an alterative entity capable of assisting the caller.
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.
Hungerford et al. (U.S. Patent Publication 2011/0099034 A1) teaches a method is provided for displaying medically related tasks on a patient viewable display in an in-patient care setting by receiving a clinical order, automatically generating corresponding tasks, and optionally linking them to the patient’s electronic medical records for retrieval and display.
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