DETAILED ACTION
Status
This Office Action is in response to the communication filed on 24 February 2026. Claims 1-20 have been cancelled currently or previously, no claims have been amended, and new claims 21-39 have been added. Therefore, claims 21-39 are pending and presented for examination.
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 .
Response to Amendment
A summary of the Examiner’s Response to Applicant’s amendment:
Applicant’s amendment overcomes the previous claim objection(s); therefore, the Examiner withdraws the objection(s).
Applicant’s amendment overcomes the rejection(s) under 35 USC § 112; therefore, the Examiner withdraws the rejection(s).
Applicant’s amendment does not overcome the rejection(s) under 35 USC § 101; therefore, the Examiner maintains the rejection(s) while updating phrasing in keeping with current examination guidelines.
Applicant’s amendment overcomes the rejection(s) under 35 USC §§ 102 and/or 103; therefore, the Examiner places new grounds of rejection.
Applicant’s arguments are found to be not persuasive; please see the Response to Arguments below.
Priority
Applicant’s claim for the benefit under 35 U.S.C. 119(e) to U.S. Provisional Application Nos. 63/232,424 and 63/232,427, both filed on 12 August 2021, is acknowledged.
However, the Examiner notes that it appears that neither of the above listed Provisionals mention or support activity in relation to at least a delivery receipt. Therefore, no priority benefit appears available for the current claims. The Examiner further notes that Provisional Application 63/232,424 does not discuss translation.
Claim Interpretation
Applicant’s claims recite multiple acronyms without an explanation or definition that limits the claimed acronyms, as well as some terms that are not defined; therefore, the Examiner is interpreting (per the light of the specification) the following acronyms and terms as:
RCS: Rich Communication Services (at Applicant ¶ 0044)
SMS: Short Messaging System (Id. at 0005), or Short Message Service (per NPL Xfinity Hub, as indicated below at pertinent prior art, at 2).
A software middleware layer: Applicant’s only description related to this is Applicant ¶¶ 0019-0020, indicating that “A software middleware layer 104 connects to the EMR system 102 and also connects to one or more mobile device 106 or computer 108 to provide EMR notification messages” and “the software middleware layer 104 will be a tool that enables different stakeholders to communicate”. As such this is interpreted as any messaging platform, and would inherently “process[ ]” any messages (including translated messages) and notifications.
The Examiner notes that Applicant mixes “platform” and “type” as though they are essentially the same – noting that original claims 4-5 list iOS, SMS, and email as both a message platform and a message type.
Dependent claim 22 recites “wherein the service engine maintains a message state machine having states comprising at least "created," "sent," "delivered," and "read," and wherein updating the selected patient record comprises writing the state machine state to the selected patient record”.
The Examiner notes that the exact terminology (e.g., “sent”, “delivered”, etc., as opposed to, or rather than, similar terminology such as “mailed” or “received”) is not patentable since this appears to be printed matter. See, e.g., MPEP § 2111.05. There is no apparent indication of any functional relationship between the terminology of these labels (as opposed to other or similar indications that may mean the same or similar things) and any associated substrate. The indications of these labels for a state or status appear to merely be conveying a message or meaning to a human reader independent of the supporting product.
Further, there is no indication of, or written support regarding, a “state machine”
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 21-39 are 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.
Independent claim 21 recites “one or more asynchronous event listeners configured to receive delivery receipts and read receipts as callback events” and independent claim 32 recites “registering asynchronous receipt callbacks for delivery receipts and read receipts”. The Examiner has searched for the concept of any receipts being asynchronous and does not find it. The term “asynchronous”, is not used or defined in the specification, but apparently means “not simultaneous or concurrent in time” per the Merriam-Webster definition below at the pertinent prior art. The only reference in the specification that appears at all related is Applicant ¶ 0043 (as submitted, 0068 as published) indicating “The read receipts will be stored in the personal history of the patient with relevant fields such as date / time message sent and date / time message read”. So there apparently is a timestamp for the read and delivery receipts, but there is no indication that whatever is used to receive those receipts, or the receipts themselves, or any registering of the receipts (as callbacks or callback events) is asynchronous.
Claims 22-31 and 33-39 depend from claims 1 and 39, but do not resolve the above issues and inherit the deficiencies of the parent claim(s); therefore claims 22-31 and 33-39 are also lacking written support.
Dependent claims 22 and 35 recite that “the service engine maintains a message state machine”, where claim 22 also indicates “updating the selected patient record comprises writing the state machine state to the selected patient record” and claim 35 indicates “and updates the message status by transitioning the state machine responsive to callback events”. The Examiner has searched for, but does not find, any indication of a state machine. As understood via the pertinent prior art below (see, e.g., Shead, fmitchell, and/or the Microsoft learning paper) a state machine is a particular type of “machine” programmed to record the current state of something based on inputs or events.
The Examiner notes that “state” is only mentioned at Applicant ¶ 0027, indicating “REST API (Representational State Transfer Application Programming Interface)”, rather than a state machine. And “machine” is only mentioned in reference to machine translation (at Applicant ¶ 0029), “machine learning training” (at Applicant ¶ 0080), and “machine learning” models or circuitry (at Applicant ¶ 0081). Therefore, there is no indication of any conception of using a state machine, as far as the Examiner can determine.
Dependent claim 26 recites that “the service engine processes the callback events from the queue in timestamp order”. The Examiner has searched for the concept of any receipts being processed in timestamp order and does not find it. The only reference in the specification that appears at all related is Applicant ¶ 0043 (as submitted, 0068 as published) indicating “The read receipts will be stored in the personal history of the patient with relevant fields such as date / time message sent and date / time message read”. So there apparently is a timestamp for the read and delivery receipts, but there is no indication of a processing order for a queue as far as the Examiner has been able to determine.
Claim 33 recites “wherein the middleware layer comprises an event listener and a message queue storing callback events”. The Examiner has searched for the concept of middleware comprising a message queue storing callback events and does not find it. The only references to middleware in the specification are Applicant ¶¶ 0019-0020 indicating “A software middleware layer 104 connects to the EMR system 102 and also connects to one or more mobile device 106 or computer 108 to provide EMR notification messages” (at 0019) and “the software middleware layer 104 includes application programming interface (API) connections to different messaging protocols, that enable the EMR system 102 to interface to applications on the mobile device 106 and computer 108. According to further aspects of FIG. 1, the software middleware layer 104 will be a tool that enables different stakeholders to communicate. For example, the middleware layer 104 will enable patient to communicate with a coordinator, a coordinator to communicate with a pharmacy, and a coordinator to communicate with a physician.” The “callback events” are “delivery receipt and read receipt callback events” per parent claim 32, so the middleware may enable communication, but there is no indication of middleware having a queue storing the delivery and/or read receipts.
Claim 34 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 34 recites “wherein the platform-specific messaging module comprises at least one of an SMS module, an RCS module, and an iMessage module”; however, parent claim 32 already recites “determining a supported messaging protocol of a recipient mobile device comprising at least one of SMS, RCS, or iMessage; [and] selecting a platform-specific messaging module based on the supported messaging protocol. Since claim 32 already requires the supported protocol to be SMS, RCS, and/or iMessage, and the selected module must be one of those supported protocols, claim 34 only recites that which is already apparently required at parent claim 32. As such, claim 34 fails to further limit the subject matter of the claim upon which it depends
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 21-39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Please see the following Subject Matter Eligibility (“SME”) analysis:
For analysis under SME Step 1, the claims herein are directed to a method (claims 21-31) and system (claims 32-39), which would be classified under one of the listed statutory classifications (SME Step 1=Yes).
For analysis under revised SME Step 2A, Prong 1, independent claim 21 recites a computer-implemented method for integrating text messaging read notification with an electronic medical record (EMR) system, the method executed by a service engine comprising one or more processors and memory storing instructions that cause the service engine to:
receive, from a user device associated with a clinician, a message input and a selected patient record in the EMR system;
generate a message instance comprising a correlation identifier associated with the selected patient record;
determine, by querying a recipient device capability record or by transmitting a capability query, a supported messaging protocol of a recipient mobile device, the supported messaging protocol comprising at least one of SMS, RCS, or iMessage;
select, based on the supported messaging protocol, a platform-specific messaging module to transmit the message instance via the selected messaging protocol;
when a language difference is detected between a clinician language and a recipient language, invoke a translation service prior to transmitting to generate translated content, and include the translated content in the message instance;
transmit the message instance to the recipient mobile device via the selected messaging protocol;
register, in a middleware layer, one or more asynchronous event listeners configured to receive delivery receipts and read receipts as callback events from a messaging platform or carrier network;
receive, via the middleware layer, a delivery receipt event and/or a read receipt event for the message instance;
correlate the delivery receipt event and/or the read receipt event to the message instance using the correlation identifier; and
update the selected patient record in the EMR system with a message status based on the correlated event.
Independent claim 31 is similar to claim 1, except directed to an EMR notification system for integrating text messaging read notification with an EMR system, comprising:
an EMR server comprising a database storing patient records;
a service engine comprising one or more processors and memory storing instructions that, when executed, cause the service engine to perform operations comprising the same or similar activities as at claim 21 above.
The dependent claims (claims 22-31 and 33-39) appear to be encompassed by the abstract idea of the independent claims since they merely indicate recording the message state in a state machine (claims 22 and 35), matching the correlation identifier to a log entry (claim 23), determining RCS is supported, and when it is not, selecting SMS (claim 24), selecting from RCS, SMS, or iMessage (claims 25 and 34), the “event listeners” store events and they are processed in timestamp order (claims 26 and 33), a carrier-provided delivery confirmation and platform-provided read confirmation (claim 27), invoking the translation service generates a bilingual text message (claim 28), transmitting a clinician facing notification reflecting the updated status (claims 29 and 39), the middleware layer comprising an API to receive events (claim 30), updating the patient record automatically without manual entry (claims 31 and 38), the supported message protocol determined by query and storing the results (claim 36), and/or the bilingual message being in English and a non-English language (claim 37).
The underlined portions of the claims are an indication of elements additional to the abstract idea (to be considered below).
The claim elements may be summarized as the idea of determining how communicate and recording that a message has been sent, delivered, and/or received; however, the Examiner notes that although this summary of the claims is provided, the analysis regarding subject matter eligibility considers the entirety of the claim elements, both individually and as a whole (or ordered combination). This idea is within the certain methods of organizing human activity (e.g., … commercial or legal interactions such as agreements, contracts, legal obligations, advertising, marketing or sales activities/behaviors, or business relations; and/or managing personal behavior or relationships between people such as social activities, teaching, and following rules or instructions) grouping of subject matter. The claims, other than the use of text messaging, appear analogous to looking up or asking how to communicate with a person (such as a patient, and by mail, delivery service, email, phone call, etc.) and recording the status of communication similar to legal service (the confirmation of patient communication having fiduciary and legal implications, requirements, or ramifications).
Therefore, the claims are found to be directed to an abstract idea.
For analysis under revised SME Step 2A, Prong 2, the above judicial exception is not integrated into a practical application because the additional elements do not impose a meaningful limit on the judicial exception when evaluated individually and as a combination. The additional elements are the method being computer-implemented, using an electronic medical record (EMR) system, the method executed by a service engine comprising one or more processors and memory storing instructions that cause the service engine to receive, from a user device, querying a recipient device for a protocol of the recipient mobile device, the protocol being one of SMS, RCS, or iMessage; receiving delivery/read receipts in a middleware layer, events from a messaging platform or carrier network (at claim 21) and the indication of an EMR system, the EMR system, comprising an EMR server (comprising a database), a service engine comprising one or more processors and memory storing instructions that, when executed, cause the service engine to perform operations (at claim 32), and a state machine (at claims 22 and 35).
These additional elements do not reflect an improvement in the functioning of a computer or an improvement to other technology or technical field, effect a particular treatment or prophylaxis for a disease or medical condition (there is no medical disease or condition, much less a treatment or prophylaxis for one), implement the judicial exception with, or by using in conjunction with, a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing (there is no transformation/reduction of a physical article), and/or apply or use the judicial exception in some other meaningful way beyond generically linking use of the judicial exception to a particular technological environment.
The claims merely generally link the abstract idea to the use of generic computers, devices, or technology via the indication of the additional elements.
The claims appear to merely apply the judicial exception, include instructions to implement an abstract idea on a computer, or merely use a computer as a tool to perform the abstract idea. The additional elements appear to merely add insignificant extra-solution activity to the judicial exception and/or generally link the use of the judicial exception to a particular technological environment or field of use.
For analysis under SME Step 2B, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, as indicated above, are merely “[a]dding the words ‘apply it’ (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp.” that MPEP § 2106.05(I)(A) indicates to be insignificant activity.
Further, even if the additional elements were considered, the Examiner notes that MPEP § 2106.05(d)(II) indicates examples of elements that the courts have recognized as well-understood, routine, and conventional activity, including “[r]eceiving or transmitting data over a network, e.g., using the Internet to gather data” (citing to Symantec, TLI Comms. OIP Techs., buySAFE), “[e]lectronic recordkeeping” (Alice, Ultramercial) and “[s]toring and retrieving information in memory” (Versata, OIP Techs.).
There is no indication the Examiner can find in the record regarding any specialized computer hardware or other “inventive” components, but rather, the claims merely indicate computer components which appear to be generic components and therefore do not satisfy an inventive concept that would constitute “significantly more” with respect to eligibility. Applicant ¶¶ 0080-0081, as submitted, indicates the implementation and functions described as stored on a medium and performed by a computer or processor that is indicated as merely being or requiring a general purpose processor.
The individual elements therefore do not appear to offer any significance beyond the application of the abstract idea itself, and there does not appear to be any additional benefit or significance indicated by the ordered combination, i.e., there does not appear to be any synergy or special import to the claim as a whole other than the application of the idea itself.
The dependent claims, as indicated above, appear encompassed by the abstract idea since they merely limit the idea itself; therefore, the dependent claims do not add significantly more than the idea.
Therefore, SME Step 2B=No, any additional elements, whether taken individually or as an ordered whole in combination, do not amount to significantly more than the abstract idea, including analysis of the dependent claims.
Please see the Subject Matter Eligibility (SME) guidance and instruction materials at https://www.uspto.gov/patent/laws-and-regulations/examination-policy/subject-matter-eligibility, which includes the latest guidance, memoranda, and update(s) for further information.
NOTICE
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 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.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 21, 23-34, and 36-39 are rejected under 35 U.S.C. 103 as being unpatentable over Mumick et al. (U.S. Patent Application Publication No. 2023/0262427, hereinafter Mumick) in view of Nusimow et al. (U.S. Patent Application Publication No. 2013/0041677, hereinafter Nusimow) .
Claim 21: Mumick discloses a computer-implemented method for integrating text messaging read notification …, the method executed by a service engine comprising one or more processors and memory storing instructions that cause the service engine (see Mumick at least at, e.g., ¶ 0085, “The system 600 further comprises the expanded reach rich messaging application (ERRMA) 202 configured to define computer program instructions executable by at least one processor 601”; citation hereafter by number only) to:
receive, from a user device …, a message input (Mumick at 0007, “enabling processing of messages sent as rich messages for one specified rich messaging channel to create equivalent rich messages and automatically sending the created equivalent rich messages over an alternative rich messaging channel, if the user has access to the alternative rich messaging channel”);
generate a message instance comprising a correlation identifier associated with the selected (Mumick at 0009, “identify the user by their mobile number.… In an embodiment, a chatbot of the entity may ask the user to provide and validate a mobile number, thereby establishing a mapping between the channel-specific identifier and the user's mobile number”, 0010, “The user device is addressed by the user's mobile number or an identifier mapped to the user's mobile number”);
determine, by querying a recipient device capability record or by transmitting a capability query, a supported messaging protocol of a recipient mobile device, the supported messaging protocol comprising at least one of SMS, RCS, or iMessage (Mumick at 0008, “A user can select or tap a suggested reply button or a suggested action button to send a response message or to take an action on a user device. A suggested reply allows the user to select or tap on an interactive button displayed on the user device to communicate a response to an entity, for example, a business entity, an enterprise, or an organization identified by or associated with one or more brands. A suggested action allows the user to select or tap on an interactive button to take an action on the user device, for example, make a phone call, open a website, share a location, etc. On the RCS channel, the suggested replies and the suggested actions are sent as part of a suggested chip list, or along with a standalone rich card, or with a rich card as part of a carousel. Other messaging channels also support sending of interactive buttons in the form of suggested replies and suggested actions, though these rich interactive elements may be referred by a different term. For example, on the WhatsApp® instant messaging application, a suggested reply is called a quick reply and a suggested action is called a call-to-action, and on the Facebook® Messenger, a suggested reply is called a quick reply and a suggested action is in the form of a button”, 0010, “an expanded reach rich messaging application (ERRMA) … The ERRMA determines whether the user's mobile number is enabled for receiving the rich message on the specified rich messaging channel. Upon successful determination that the user's mobile number is enabled for receiving the rich message on the specified rich messaging channel, the ERRMA creates and transmits the rich message on the specified rich messaging channel to the user's mobile number. Upon determining that the user's mobile number is not enabled for receiving the rich message on the specified rich messaging channel, the ERRMA determines whether the user's mobile number is enabled for receiving the rich message on an alternative rich messaging channel. Upon determining that the user's mobile number is enabled for receiving the rich message on the alternative rich messaging channel, the ERRMA creates and transmits an equivalent rich message on the alternative rich messaging channel to a user device. The user device is addressed by the user's mobile number or an identifier mapped to the user's mobile number”);
select, based on the supported messaging protocol, a platform-specific messaging module to transmit the message instance via the selected messaging protocol (Mumick at 0013, “The ERRMA identifies whether a recipient of the rich message is active on the specified rich messaging channel or on one or more of multiple alternative rich messaging channels. The ERRMA creates an equivalent rich message if the recipient of the rich message is active on one or more of the alternative rich messaging channels”);
transmit the message instance to the recipient mobile device via the selected messaging protocol (Mumick at 0013, “The ERRMA identifies whether a recipient of the rich message is active on the specified rich messaging channel or on one or more of multiple alternative rich messaging channels. The ERRMA creates an equivalent rich message if the recipient of the rich message is active on one or more of the alternative rich messaging channels”);
register, in a middleware layer, one or more asynchronous event listeners configured to receive delivery receipts and read receipts as callback events from a messaging platform or carrier network (Mumick at 0099, “The feedback module 202h also provides feedback to the entity or the developer 201 on behalf of the entity about the delivery status and the read receipt of the rich message, to allow the entity to take an appropriate action.… Sending of the status message comprises sending one or more of a delivery receipt and a read receipt to the entity/developer”);
receive, via the middleware layer, a delivery receipt event and/or a read receipt event for the message instance (Mumick at 0099, “The feedback module 202h also provides feedback to the entity or the developer 201 on behalf of the entity about the delivery status and the read receipt of the rich message, to allow the entity to take an appropriate action.… Sending of the status message comprises sending one or more of a delivery receipt and a read receipt to the entity/developer”);
correlate the delivery receipt event and/or the read receipt event to the message instance using the correlation identifier (Mumick at 0099, “The feedback module 202h also provides feedback to the entity or the developer 201 on behalf of the entity about the delivery status and the read receipt of the rich message, to allow the entity to take an appropriate action.… Sending of the status message comprises sending one or more of a delivery receipt and a read receipt to the entity/developer”); and
update with a message status based on the correlated event (Mumick at 0057, “The ERRMA receives 106 a status from a user device of the user and sends a status response to the entity or a developer on behalf of the entity. The status response indicates one or more of a delivery of the rich message to the user device, that is, a delivery receipt; a timeout without delivery of the rich message; a confirmation of the rich message having been read, that is, a read receipt; the rich messaging channel used to transmit the rich message; an indication that the user's mobile number is not enabled for any of the rich messaging channels, etc.”).
Mumick, however, does not appear to explicitly disclose the messaging being with an electronic medical record (EMR) system, the device being associated with a clinician, a selected patient record in the EMR system, correlation with a patient record, when a language difference is detected between a clinician language and a recipient language, invoke a translation service prior to transmitting to generate translated content, and include the translated content in the message instance; and that the update is to the selected patient record in the EMR system. Nusimow, though, teaches that although “Communications between the potentially geographically distributed computing and storage resources comprising the message management system 120 are not shown” in the figure(s) “the EHR system 120 is implemented on one or more computing resources” (Nusimow at 0052) and “The external sources 110 are coupled in communication to the EHR system 120 via the network 140” (Nusimow at 0050), the communicating being with doctors, staff, and/or practitioners (Nusimow at 0036, 0040, 0043) regarding appointments such as “a patient visit, phone call, or other patient/practitioner interaction that could result in a modification of that patient's medical record” (Nusimow at 0032), including “[d]uring a visit, the doctor can use one or more forms 270 (either custom or system provided) to update clinical information 260 that is associated with the visit. For example, storing a record of currently taken prescription drugs is a common set of information captured. The EHR system 120 can then automatically generate a clinical narrative 265 for the visit from the doctor entered information” (Nusimow at 0071), and that “translation can be done on the end point 130 or on the EHR system 120. In some embodiments, the form fields are automatically translated, in others, the form fields are selected by a practitioner or doctor with specific knowledge of the language that the specific form will be using (for example, the doctor may make an English form and then also make a Spanish form--specifically editing field names using the form editor)” (Nusimow at 0093). Therefore, the Examiner understands and finds that to provide messaging with clinicians to update a correlated specific patient record and invoke a translation service is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to automatically update the proper patient record and communicate across language differences.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine or modify the receipting of Mumick with the EMR updating and translating of Nusimow in order to provide messaging with clinicians to update a correlated specific patient record and invoke a translation service so as to automatically update the proper patient record and communicate across language differences.
The rationale for combining in this manner is that to provide messaging with clinicians to update a correlated specific patient record and invoke a translation service is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to automatically update the proper patient record and communicate across language differences as explained above.
Claim 23: Mumick in view of Nusimow discloses the method of claim 21, wherein correlating comprises matching the correlation identifier to a stored message log entry that includes a patient identifier and a message identifier (Mumick at 0009-0010, identifier mapping).
Claim 24: Mumick in view of Nusimow discloses the method of claim 21, wherein determining the supported messaging protocol comprises determining whether the recipient mobile device supports RCS, and when RCS is unsupported, selecting SMS (Mumick at 0018, “Upon determination that the user's mobile number has not exchanged the equivalent RCS messages on the alternative rich business messaging channel, the ERRMA creates an internal identifier configured to securely map to the user's mobile number; creates an equivalent short message service (SMS) message comprising a uniform resource locator (URL) encoded with the internal identifier; transmits the created equivalent SMS message”).
Claim 25: Mumick in view of Nusimow discloses the method of claim 21, wherein selecting the platform-specific messaging module comprises selecting from an SMS module, an RCS module, and an iMessage module (Mumick at 0009, “As used herein, “channel” exemplarily refers to a short message service (SMS) channel, an RCS channel, a WhatsApp® messaging channel, the iMessage® messaging channel”, 0018, SMS used, 0046, “The specified rich messaging channel and the alternative rich messaging channel comprise, for example, any one of a rich communication services (RCS) channel, WhatsApp® messaging channel of WhatsApp LLC, iMessage® of Apple, Inc., Telegram® of Telegram FZ-LLC, Viber® of Viber Media SARL, Signal® of Signal Technology Foundation, Google Business Messages of Google LLC, Business Chat® of Apple, Inc., Facebook® Messenger of Facebook, Inc., or any other messaging channel”).
Claim 26: Mumick in view of Nusimow discloses the method of claim 21, wherein the asynchronous event listeners include a queue that stores callback events and the service engine processes the callback events from the queue in timestamp order (Mumick at 0014, “history of the recipient in terms of message delivery status, message delivery time, message read status, message read time, and user response”).
Claim 27: Mumick in view of Nusimow discloses the method of claim 21, wherein receiving the delivery receipt event comprises receiving a carrier-provided delivery confirmation, and receiving the read receipt event comprises receiving a platform-provided read confirmation (Mumick at 0014, “history of the recipient in terms of message delivery status, message delivery time, message read status, message read time, and user response” – where the delivery is understood to be confirmed by the carrier, and the reading, or not reading, is confirmed by a platform).
Claim 28: Mumick in view of Nusimow discloses the method of claim 21, wherein invoking the translation service comprises generating a bilingual text message including a first language text and a second language text (Nusimow at 0093, “translation can be done on the end point 130 or on the EHR system 120. In some embodiments, the form fields are automatically translated, in others, the form fields are selected by a practitioner or doctor with specific knowledge of the language that the specific form will be using (for example, the doctor may make an English form and then also make a Spanish form--specifically editing field names using the form editor)”, as combined above and using the rationale as at the combination above).
Claim 29: Mumick in view of Nusimow discloses the method of claim 21, further comprising transmitting, to the user device, a clinician-facing notification reflecting the updated message status in the EMR system (Mumick at 0012, “the ERRMA receives a status message from the alternative rich messaging channel and sends the status message to the entity on the specified rich messaging channel. Sending of the status message comprises sending one or more of a delivery receipt and a read receipt to the entity” – where, as indicated by the combination above, since the message may be from a clinician, the sending of a receipt to the entity is a clinician-facing notification).
Claim 30: Mumick in view of Nusimow discloses the method of claim 21, wherein the middleware layer comprises an application programming interface (API) endpoint configured to receive the callback events from the messaging platform (Mumick at 0016, “The methods disclosed above are executed using one or more application programming interfaces (APIs)”).
Claim 31: Mumick in view of Nusimow discloses the method of claim 21, wherein updating the selected patient record is performed automatically by the service engine without manual entry by the clinician after transmission of the message instance (Nusimow at 0071 “The EHR system 120 can then automatically generate a clinical narrative 265 for the visit”).
Claim 32 is rejected on the same basis as claim 21 above since at least Mumick discloses an EMR notification system for integrating text messaging read notification with an EMR system, comprising: an EMR server comprising a database storing patient records; a service engine comprising one or more processors and memory storing instructions that, when executed, cause the service engine to perform operations (see Mumick at least at 0085, as above) comprising the same or similar activities as at claim 21 above.
Claim 33: Mumick in view of Nusimow discloses the system of claim 32, wherein the middleware layer comprises an event listener and a message queue storing callback events (Mumick at 0014, “history of the recipient in terms of message delivery status, message delivery time, message read status, message read time, and user response”, 0099, “The feedback module 202h also provides feedback to the entity or the developer 201 on behalf of the entity about the delivery status and the read receipt of the rich message, to allow the entity to take an appropriate action.… Sending of the status message comprises sending one or more of a delivery receipt and a read receipt to the entity/developer”);.
Claim 34: Mumick in view of Nusimow discloses the system of claim 32, wherein the platform-specific messaging module comprises at least one of an SMS module, an RCS module, and an iMessage module (Mumick at 0009, “As used herein, “channel” exemplarily refers to a short message service (SMS) channel, an RCS channel, a WhatsApp® messaging channel, the iMessage® messaging channel”, 0018, SMS used, 0046, “The specified rich messaging channel and the alternative rich messaging channel comprise, for example, any one of a rich communication services (RCS) channel, WhatsApp® messaging channel of WhatsApp LLC, iMessage® of Apple, Inc., Telegram® of Telegram FZ-LLC, Viber® of Viber Media SARL, Signal® of Signal Technology Foundation, Google Business Messages of Google LLC, Business Chat® of Apple, Inc., Facebook® Messenger of Facebook, Inc., or any other messaging channel”).
Claim 36: Mumick in view of Nusimow discloses the system of claim 32, wherein the supported messaging protocol is determined by performing a device capability query and storing results in a device capability record (Mumick at 0018, “Upon determination that the user's mobile number has not exchanged the equivalent RCS messages on the alternative rich business messaging channel, the ERRMA creates an internal identifier configured to securely map to the user's mobile number; creates an equivalent short message service (SMS) message comprising a uniform resource locator (URL) encoded with the internal identifier; transmits the created equivalent SMS message”).
Claim 37: Mumick in view of Nusimow discloses the system of claim 32, wherein the translation module produces a bilingual message comprising text in English and text in a non-English language (Nusimow at 0093, “translation can be done on the end point 130 or on the EHR system 120. In some embodiments, the form fields are automatically translated, in others, the form fields are selected by a practitioner or doctor with specific knowledge of the language that the specific form will be using (for example, the doctor may make an English form and then also make a Spanish form--specifically editing field names using the form editor)”, as combined above and using the rationale as at the combination above).
Claim 38: Mumick in view of Nusimow discloses the system of claim 32, wherein the service engine updates the selected patient record automatically without requiring manual clinician confirmation after the callback events are received (Nusimow at 0071 “The EHR system 120 can then automatically generate a clinical narrative 265 for the visit”).
Claim 39: Mumick in view of Nusimow discloses the system of claim 32, wherein the service engine produces a clinician-facing interface indicating delivery and read status for the message instance and the selected patient record (Mumick at 0012, “the ERRMA receives a status message from the alternative rich messaging channel and sends the status message to the entity on the specified rich messaging channel. Sending of the status message comprises sending one or more of a delivery receipt and a read receipt to the entity” – where, as indicated by the combination above, since the message may be from a clinician, the sending of a receipt to the entity is a clinician-facing notification).
Claims 22 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Mumick in view of Nusimow in further view of Hanina et al. (U.S. Patent Application Publication No. 2012/0316897, hereinafter Hanina) .
Claim 22: Mumick in view of Nusimow discloses the method of claim 21, but does not appear to explicitly disclose wherein the service engine maintains a message state machine having states comprising at least "created," "sent," "delivered," and "read," and wherein updating the selected patient record comprises writing the state machine state to the selected patient record. Where Mumick discloses the message state (as cited above at the parent claim(s), Mumick does not disclose the use of a state machine. Hanina, though, teaches that “the present invention will provide a state machine … [with v]arious embodiments of the inventive solution, including the described state machine, provide data relevant to medication adherence and other medical treatments as opposed to entire patient history, such as in an existing electronic medical record”. Therefore, the Examiner understands and finds that to use a state machine with respect to providing data for an EMR is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to automatically update the proper patient record.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine or modify the receipting of Mumick in view of Nusimow with the state machine of Hanina in order to use a state machine with respect to providing data for an EMR so as to automatically update the proper patient record.
The rationale for combining in this manner is that to use a state machine with respect to providing data for an EMR is applying a known technique to a known device, method, or product ready for improvement to yield predictable results so as to automatically update the proper patient record as explained above.
Claim 35 depends from independent claim 32 and is rejected on the same basis as claim 22 above.
Response to Arguments
Applicant's arguments filed 24 February 2026 have been fully considered but they are not persuasive.
Applicant first argues the 112 rejection(s) (Remarks at 7); however, the amendment canceling the previous claims overcomes the rejection(s). Therefore, the argument is considered moot and not persuasive.
Applicant next argues the 101 rejections (Remarks at 7-9), first referring to “OA3” (Id. at 7); however, it is not clear what “OA3” refers to – the Examiner is merely assuming this a reference to the Non-Final Office Action dated 24 November 2025.
Applicant then alleges “a specific, computer- implemented orchestration mechanism” and that “[t]he claims require concrete technical features” (Id. at 8). However this argument appears to be attempting to address elements that are additional to the indications of an abstract idea – i.e., that it is “computer-implemented”, and has “concrete” features. However, having elements additional to the indications of the abstract idea does not mean that a claim is not directed to a/the abstract idea – the additional features are addressed later in the eligibility analysis. Further, the Examiner notes the lack of support for some of the argued features, and that the “middleware” is described as merely software for performing operations or activities (e.g., “apply it” via a computer).
Applicant then argues that “This is not a claim to a desired result …, but a particular control architecture and workflow” (Id.). However – again ignoring the apparent lack of support for some of the concepts indicated, people have tracked messages to others – including messages in the medical or healthcare field generally – and recorded the same.
Applicant then argues that the “Amended Claims Recite an Inventive Concept” (Id. at 8), in “registering asynchronous delivery/read receipt callbacks via middleware”, “receiving callback events from external systems”, “correlating events to a message instance and EMR record using a correlation identifier”, and “updating EMR state based on those correlated events, optionally including protocol selection based on recipient capability and pre-delivery translation gating” (Id.). However, that is the abstract idea – the “callback events” are the delivery/read receipts, that are “register[ed]” by using a “correlation identifier” such as phone number or account number so that the person’s medical record includes a note or indication that a message was sent, delivered, and/or read. This is not a technical solution – it is merely using technology to do what people would or could otherwise do: Track messages to a person and record whether that person has been informed, or to what level they have been informed.
Applicant then argues the prior art rejection(s) (Remarks at 9-10); however, the amendments necessitate new grounds of rejection as indicated above. Therefore, the argument is considered moot and not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
What’s the Difference Between iMessages & Text Messages?, Xfinity Discovery Hub, dated 8 April 2020, downloaded 19 June 2024 from https://www.xfinity.com/hub/mobile/difference-between-imessages-and-sms-messages#:~:text=iMessages%20only%20work%20between%20iPhones,message%20is%20on%20Android%20too.) (hereinafter, Xfinity Hub), indicating all devices must be Apple devices for iMessages or SMS is automatically used (“iMessages only work between iPhones (and other Apple devices such as iPads). If you are using an iPhone and you send a message to a friend on Android, it will be sent as a SMS message and will be green. (This is true if just one person in a group message is on Android too.) If there is no available data network, messages to other iPhones will also be sent as SMS text messages” – Xfinity Hub at 2).
FHIR Specification, Publication (Version) History, HL7.org, downloaded from https://hl7.org/fhir/directory.html on 20 June 2024, indicating the history and release dates of FHIR, including the original proposal in 2011.
HL7 FHIR Release 5, HL7.org, downloaded from https://www.hl7.org/fhir/ on 20 June 2024, indicating “FHIR is a standard for health care data exchange, published by HL7®”.
What is FHIR, from The Office of the National Coordinator for Health Information Technology, downloaded from https://www.healthit.gov/sites/default/files/2019-08/ONCFHIRFSWhatIsFHIR.pdf on 20 June 2024, indicating that “The HL7® FHIR® (Fast Healthcare Interoperability Resources 1 ) standard defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems. It allows healthcare information, including clinical and administrative data, to be available securely to those who have a need to access it, and to those who have the right to do so for the benefit of a patient receiving care. The standards development organization HL7® (Health Level Seven®3) uses a collaborative approach to develop and upgrade FHIR.”
Posey, Brian, Apple iOS, TechTarget.com, downloaded 20 June 2024 from https://www.techtarget.com/searchmobilecomputing/definition/iOS (hereinafter, Posey), indicating that “Apple iOS was originally known as iPhone OS .... It premiered alongside Apple's iPhone 3G. This operating system was followed on June 17, 2009 by iOS 3. The fourth version of iOS was released on June 21, 2010, along with the iPhone 4” (at 2).
The Oscar Story, The Well EMR Group, downloaded 15 June 2024 from https://oscarpro.ca/the-oscar-story/, indicating that “In 2001, McMaster University’s Department of Family Medicine created OSCAR” (at 2) and “OSCAR Pro [was] launched” in 2020 (at 3).
OSCAR User’s Manual, downloaded via the WayBack Machine of Archive.org at https://web.archive.org/web/20171215104814/http://oscarmanual.org/introduction/OSCAR%20Manual%20version%202.pdf on 15 June 2024, dated 15 December 2017, indicating the features and capabilities of OSCAR. The Examiner notes that the WayBack Machine header has been included at the first page to indicate a date of availability.
Turinas et al. (U.S. Patent Application Publication No. 2014/0039912, hereinafter Turinas) describes “An integrated digital mobile communications management system having HIPAA compliant text, email, and image capability that complies with medical record maintenance requirements and facilitates physician/provider utilization of a healthcare system's resources is presented. The mobile platform capabilities include selection of physician/providers based on specialty, practice interests and medical insurance plan participation, the scheduling of physician/provider referrals and medical procedures, various bilateral communications between healthcare providers and healthcare systems, reporting of physician/provider location, and provision of medical information and delivering news and alerts. The management system includes a mobile digital smart-device App that verifies users, encrypts and decrypts electronic messages, and transmits and receives electronic messages. Encrypted messages are securely stored, and automatically incorporated into patients' healthcare records. The App provides a mobile digital communication management platform that integrates messaging capabilities with a hospital scheduling system to facilitate quick and easy scheduling of medical procedures and physician/provider consultations.” (Turinas at Abstract), where “The mobile App operates cross mobile platforms (iPhone, iPad, android smartphones and tablets) giving individuals the ability to use the platform most advantageous to the individual for their type of position within the healthcare system.” (Turinas at 0024) so as “to provide a secure, automated means of updating electronic patient health record information with communications between and among physician/providers and nurses and/or other personnel” (Turinas at 0029).
Orueta, Josh, HIPAA-Compliant Text Message Appointment Reminders, updated 26 January 2022, downloaded from https://www.bridgeinteract.io/blog/how-to-send-automated-hipaa-compliant-text-message-appointment-reminders/ on 19 November 2025, indicating bilingual text message capabilities being available.
Shead, Understanding State Machines, downloaded from https://www.freecodecamp.org/news/state-machines-basics-of-computer-science-d42855debc66/#:~:text=In%20simpler%20terms%2C%20a%20state,it%20is%20really%20quite%20simple on 26 May 2026, dated 11 February 2018, indicating “A finite state machine is a mathematical abstraction” such that “When it reads an input, it will switch to a different state. Each state specifies which state to switch to, for a given input.” (Shead at p. 2).
fmitchell, State Machine, last updated 8 November 2018, downloaded 26 May 2026 from https://www.drupal.org/project/state_machine, indicating that a state machine “Provides code-driven workflow functionality. A workflow is a set of states and transitions that an entity goes through during its lifecycle. A transition represents a one-way link between two states and has its own label.” (at p. 1).
Microsoft, State Machine Workflows, last updated 15 September 2021, downloaded from https://learn.microsoft.com/en-us/dotnet/framework/windows-workflow-foundation/state-machine-workflows on 26 May 2026, indicating “A StateMachine activity contains the states and transitions that make up the logic of the state machine, and can be used anywhere an activity can be used” (at p. 2).
Asynchronous definition, by Merriam-Webster, downloaded 28 May 2026 from https://www.merriam-webster.com/dictionary/asynchronous, indicating a meaning of “not simultaneous or concurrent in time”, or “of, used in, or being digital (see digital sense 4) communication (as between computers) in which there is no timing requirement for transmission and in which the start of each character is individually signaled by the transmitting device” (noting that Digital, sense 4 indicates “relating to an audio recording method in which sound waves are represented digitally so that in the recording wow and flutter are eliminated and background noise is reduced”).
Digital definition, by Merriam-Webster, downloaded 28 May 2026 from https://www.merriam-webster.com/dictionary/digital, as referenced above, sense 4 indicating “relating to an audio recording method in which sound waves are represented digitally so that in the recording wow and flutter are eliminated and background noise is reduced”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT D GARTLAND whose telephone number is (571)270-5501. The examiner can normally be reached M-F 8:30 AM - 5 PM.
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 on 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.
/SCOTT D GARTLAND/
Primary Examiner, Art Unit 3685
Prosecution Insights