DETAILED ACTION
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 11 September 2026 has been entered.
Status
This Office Action is in response to the communication filed on 11 September 2026. Claims 1-20 have been cancelled currently or previously, claims 21-23, 26-28, 30, 32-35, and 37have been amended, and no new claims 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 extensive amending appears to overcome 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.
Drawings
The drawings are objected to because all of the figures, except Fig. 1, have print (font) that it too small, text that is illegible, a lack of contrast with the background (e.g., white and gray that have insufficient contrast), print that is not clear enough to be able to be read, appear to be photographs, and/or are not reproducible by means such as optical character recognition (OCR).
Since Applicant now alleges support based on the drawings alone, it is imperative that the drawings be clear and legible – see MPEP § 608.02.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
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.
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 claims 21 and 32 each now recite “a correlation identifier that uniquely identifies the message instance and is associated with the selected patient record”. Applicant apparently alleges support at Fig. 5D; however, the drawings are so unclear, lacking contrast, and of such small text font, etc. they are not legible or reproducible as required – see the Drawings Objection above (mostly now since the drawings are actually relied upon).
The Examiner notes having searched Applicant’s specification for “correlate * ”, “identif * ”, “unique * “, and only finds mention of “to identify phone type/message support stack” at Applicant ¶¶ 0037, 0038, and 0039, and “techniques to identify if phone is RCS Android® enable, iMessage® enable, or SMS enable” at Applicant ¶ 0067.
Applicant’s argument, though, at the 11 September 2026 Remarks (p. 9) appear to indicate that, based on Fig. 5D, the “correlation identifier” is, or would be, “(a) an identifier in brackets ‘[1489527872]’ that is identical across all four status entries”. But the claims require a “correlation identifier that uniquely identifies the message instance” – not that the same identifier is used for all of a series of messages, as apparently argued.
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 that uniquely identifies the message instance and is 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;
transmit the message instance to the recipient mobile device via the selected messaging protocol;
register, in a middleware layer comprising an application programming interface (API) endpoint, one or more 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, each received event comprising an event timestamp;
correlate the delivery receipt event and/or the read receipt event to the message instance using the correlation identifier; and
write, through a Fast Healthcare Interoperability Resources (FHIR) or representational state transfer (REST) application programming interface, a plurality of message log entries into a task record of the selected patient record in the EMR system, each message log entry of the plurality comprising (i) the correlation identifier, (ii) a message state of the message instance selected from queued, sent, delivered, and read, and (iii) the event timestamp of the received event from which the message state was derived, the plurality of message log entries being written in order of the event timestamps such that the selected patient record persists a time-ordered lifecycle of the message instance keyed to the correlation identifier; and
set a status of the task record to complete responsive to the read receipt event.
Independent claim 32 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 advancing the message state and recording the state in a task record (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 in a medical that a message has been queued, sent, delivered, and/or read; 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 comprising an application programming interface (API) endpoint (i.e., a URL the API uses – see the pertinent prior art below), events from a messaging platform or carrier network, and write, through a Fast Healthcare Interoperability Resources (FHIR) or representational state transfer (REST) application programming interface (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).
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.
Allowable Subject Matter
Claims 21-39 are indicated as allowable over the prior art.
The following is a statement of reasons for the indication of allowable subject matter:
The closest prior art of record appears to be Mumick et al. (U.S. Patent Application Publication No. 2023/0262427, hereinafter Mumick), indicating the message input, a correlation identifier, querying supported protocol(s), selecting a platform and transmitting a message, receiving and registering delivery receipts, correlating the receipt to the message instance and updating the message status (see the Non-Final Office Action dated 2 June 2026 for more details).
Nusimow et al. (U.S. Patent Application Publication No. 2013/0041677, hereinafter Nusimow) further teaches coupling sources with translations of information to update a correlated specific patient record and invoke a translation service (see the Non-Final Office Action dated 2 June 2026 for more details).
Tong et al. (U.S. Patent No. 11,783,922, hereinafter Tong) further teaches the use of FHIR and REST for communicating details to an EHR (see the Non-Final Office Action dated 24 November 2025 for more details).
The pertinent prior art not relied upon below further indicates that FHIR includes timestamping.
Therefore, although all the aspects of the claims appear disclosed in prior art, it does not appear reasonable to combine the various pieces of current art of record so as to arrive at the claimed invention.
Response to Arguments
Applicant's arguments filed 11 September 2026 have been fully considered but they are not persuasive.
Applicant first explains and/or argues Fig. 5D (Remarks at 8-9); however, as noted above, that figure (as well as almost all the other drawings) is/are illegible so as to know that what is claimed to be included in the figure is what is actually discernable from the current record.
Applicant next argues the 101 rejections (Remarks at 10-15), first arguing Step 2A, Prong 1 by alleging that “The Amended Claims Are Directed to a Particular Data Structure and the Automated Process That Produces It, Not to the Idea of Knowing Whether a Message Was Read” (Remarks at 10, continuing to 12). However, the Examiner notes that the claims do not recite a data structure as that term is normally used – see Wegner at the pertinent prior art below – the claims merely log a message state chronologically in the same manner as a simple written list.
After reviewing some MPEP citations, Applicant alleges that “Amended claim 21 does not recite recording that a message was read. It recites, as its output, a plurality of message log entries written into a task record of a specific patient record, where each entry is required to contain … (ii) one of four enumerated machine-observable states (queued, sent, delivered, read)” (Remarks at 11) – which means that when a message has been read, claim 21 recites recording that the message was read, despite Applicant arguing that the claim “does not recite” this very activity.
Applicant then argues “The claim is also anchored to machine-specific antecedents that have no counterpart in human communication practice: the correlation identifier exists because delivery and read receipt events arrive asynchronously from an external messaging platform or carrier network” (Id. at 11). However, there is no indication that the read receipt events must be or would be, or what is meant by, “asynchronously” – it appears this may mean merely that the message is sent at a different time than it is delivered or received. Further, there is no indication the Examiner can find regarding what constitutes a “correlation identifier” – the Examiner can only imagine that this may be the time stamp for message queueing, sending, delivery, or reading, but that is not apparently described. The “asynchronously” argument and correlation identifier appear to be arguments directed to subject matter extraneous to the specification. As the Examiner attempts to weigh the argument, “asynchronously” meaning different times for sending vs. receiving or reading appears to be the case for literally every or any message of any form, and there is no indication of granularity (i.e., that the receipt time be recorded down to the second or fraction of a second); therefore, just recording (for instance) the date in Applicant’s example would not appear to indicate asynchronous activity, nor would it indicate a correlation identifier that, per the claims, “uniquely identifies the message instance”. Therefore, the argument appears to not reflect the claim scope or breadth.
Applicant then integration to a practical application at Step 2A, Prong 2 (Remarks at 12-14), indicating a “technical problem” that “the messaging channel does not report read status back in a form the EMR can consume, and the EMR cannot itself receive or file such status” (Id. at 12); however, this does not appear to be a “technical problem” in that the solution Applicant claims is to use what Applicant admits as standard and known API capabilities to enable recording the data. See Applicant ¶ 0027: “The FIHR API (Fast Healthcare Interoperability Resources Application Programming Interface) is a standard describing data formats and elements and an application programming interface for exchanging electronic health records. The standard was created by the Health Level Seven (HL7) International health-care standards organization. The REST API (Representational State Transfer Application Programming Interface) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of an Internet-scale distributed hypermedia system, such as the Web, should behave.” The claims to recording the information in a medical record are what people have done, or could do, and the claimed solution to do this by using FHIR and/or REST APIs does not appear to change or improve any functions, problems, or issues related to the APIs or the recording. As such, it does not appear reasonable to consider this a practical application within the meaning associated with current eligibility examination guidance.
Applicant then argues Step 2B (Remarks at 14-15), alleging that
No cited authority holds it well-understood, routine, and conventional to register listeners at a middleware API endpoint for receipts originating in a carrier network, to key each outgoing message instance with a unique correlation identifier for the purpose of later reconciling asynchronously arriving events to that instance, to derive from those events an enumerated four- state lifecycle, and to write that lifecycle as timestamp-ordered, identifier-keyed entries into a task record of a third-party EMR through a FHIR/REST interface such that the terminal entry automatically completes the task. The § 112(a) analysis in the Final Office Action itself illustrates the point: the Office searched for, and did not find, these concepts in the art or the record. Final OA at 6-9.
(Id. at 14).
However, the rejection indicates the additional elements are found to be insignificant since merely applying the abstract idea by use of a generic or general-purpose computer. Applicant’s argument apparently is that if a summary of the entirety of the whole claim, including the portions indicating an abstract idea, are not well-understood, routine, or conventional (“WURC”) activity, then the claim is eligible. This essentially reduces all of eligibility analysis to not just that prior art is present, but that the prior art must recite the abstract idea and other elements as being WURC. This is certainly not the standard to be applied under the current eligibility analysis guidelines.
Applicant then argues the prior art rejection(s) (Remarks at 9-10); however, the amendments overcome the art as indicated above. Therefore, the argument is considered moot and not persuasive.
Conclusion
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”.
HL7 FHIR – 7.8 Appendix, generated 14 September 2026, downloaded 22 September 2026 from https://build.fhir.org/ehr-fm.html, indicating “ISO/HL7 10781 EHR System Functional Model Release 2 provides a reference list of functions that may be present in an Electronic Health Record System”, where the line “TI.1.5 Non-Repudiation The provenance resource tracks the timestamps, actors, and digital signatures associated with resources” further indicates timestamps are included, and the Examiner notes that “FHIR Specification, Publication (Version) History, HL7.org” above indicates Release 2 as being in 2015.
SmartBear, API Endpoints - What Are They? Why Do They Matter?, dated 1 March 2021, downloaded from The Archive.org WayBack Machine at https://web.archive.org/web/20210301233923/https://smartbear.com/learn/performance-monitoring/api-endpoints/ on 23 September 2026, indicating “Simply put, an endpoint is one end of a communication channel. When an API interacts with another system, the touchpoints of this communication are considered endpoints. For APIs, an endpoint can include a URL of a server or service. Each endpoint is the location from which APIs can access the resources they need to carry out their function” (at p. 3, under “What is an API Endpoint?). The Examiner notes that the PDF includes overlapping portions on the pages, based on the amount of the document that could be captured at each screenshot, so as to indicate continuity and completeness.
Peter Wegner and Edwin D. Reilly. 2003. Data structures. Encyclopedia of Computer Science. John Wiley and Sons Ltd., GBR, 507–512., downloaded 23 September 2026 from https://dl.acm.org/doi/10.5555/1074100.1074312, indicating “Loosely, a data structure is a structure whose components are data objects. As the term is used more precisely in computer science, a data structure is a collection of data values, the relationships among them, and the functions or operations that can be applied to the data. If any one of these three characteristics is missing or not stated precisely, the structure being examined does not qualify as a data structure” (at 507).
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
