DETAILED ACTION
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
Applicant’s amendment, filed 01/18/2026, has been entered. No claims have been cancelled and no new claims have been added. Claims 1 – 20 remain pending within the application.
Response to Arguments
Applicant's arguments filed 01/182026 have been fully considered but they are not persuasive. Particularly, Applicants arguments have merely established a highly generalized interpretation of the overarching goal of each reference. Applicant has not presented reasoning for the present applications patentability over the prior art. Instead, Applicant has merely reiterated the newly amended limitations without distinguishing these amendments from the teachings of the prior art. Indeed, Applicant’s arguments amount to a mere allegation of patentability without identifying any specific reasoning.
Even if Applicant’s arguments provided reasoning for their allegation of patentability, Examiner notes that Applicant’s amendments do not overcome the teachings of the prior art, particularly in light of the newly added Gaskill reference as laid out below, necessitated by the amendment which introduced concepts not previously present within the claims.
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
As such, the 35 U.S.C. § 103 rejections of claims 1 – 20 are maintained in light of the rejections laid out below, and for all the reasons laid out above.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3, 5 – 6, 9, and 13 – 16 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 10,542,004 B1 to Gabriel O. Perez et al. (hereinafter Perez) in view of U.S. Patent Application Publication No. 2015/0356250 A1 to Marc Polimeni (hereinafter Polimeni) in view of U.S. Patent Application Publication No. 2018/0089172 A1 to Bradford H. Needham (hereinafter Needham) and in further view of U.S. Patent Application Publication No. 2009/0058636 A1 to Robert Gaskill et al. (hereinafter Gaskill).
Regarding Claim 1, Perez teaches a method of providing multi-lingual translation of EMR notification messages to a mobile device of a recipient from an EMR system, the method comprising: (Perez teaches an EMR system sending medical notifications to patients wherein the messages may be translated. Perez at 3:24 – 4:44 and 40:17 – 42:2.)
connecting to one or more EMR system using a software middleware layer; (Perez teaches a system for providing medical notifications and information to authorized users that may be implemented as middleware (i.e., middleware connecting one or more EMR systems.) Perez at 3:24 - 4:3 and 49:6 - 49:24.)
logging into an online account of the EMR system; (Perez teaches an EMR system including a login engine for users accessing their electronic medical records. Perez at 27:5 - 31.)
creating a data message to send to a mobile platform; (Perez teaches user devices comprising mobile phones. (i.e., a mobile platform.) Perez at 32:30 - 44. Further, Perez teaches sending messages to user devices and adjusting the message prior to sending it to the user device. (i.e., creating and sending messages to a mobile platform). Perez at 3:24 - 4:54.)
processing the data message using a service engine; (Perez teaches modifying the message before transmitting the message by translating, shortening, altering, or otherwise adjusting the message and generating a notification to transmit to the user device. (i.e., processing the message using a service engine.) Perez at 43:61 - 44:44.)
receiving patient demographics and preferred language info from the EMR system; (Perez teaches storing demographic information and preferred language information in a user information database wherein the user information database is used to determine whether the message sent is to be translated by a modification engine. (i.e., the modification engine receives the demographic and preferred language information from the EMR system to determine what language to translate to.) Perez at 40:17 - 42:2.)
determining preferred language of communication; (Perez teaches translating a message between two languages based referenced information stored in the user information database (i.e., user preferred language). Perez at 41:40 - 42:2.)
and if the preferred language is English, sending the message in English to the recipient; (Perez teaches translating a message between two languages to a patient’s preferred language. Perez at 41:40 - 42:2. As such, if a patient's preferred language is English, the message is sent to the recipient in English.)
otherwise if the preferred language is a second language; (Perez teaches translating the message from the original language to a second language (i.e., Russian to English, English to Russian, etc.) Perez at 40:17 - 42:2.)
translating the message into the second language; (Perez teaches translating the message from the original language to a second language (i.e., Russian to English, English to Russian, etc.) Perez at 40:17 - 42:2.)
and sending the message in the second language to the recipient; (Perez teaches translating the message from the original language to a second language (i.e., Russian to English, English to Russian, etc.) Perez at 40:17 - 42:2.)
wherein the EMR system is configured to support a plurality EMR connectivity modules, (Perez teaches a plurality of engines (i.e., EMR connectivity modules) implemented withing the system that may be implemented as middleware Perez at 3:24 - 4:3, 49:6 - 49:24, and Fig. 10.) the EMR connectivity modules are selected from a list consisting of a Task Manager, (Perez teaches a transaction management engine operating to manage transmissions of medical-related content (i.e., task manager). Perez at 5:9 - 5:50.) a Patient lookup module, (Perez teaches an analytics and search engine that is used to evaluate which information a user is allowed to query when a user queries medical records/medical information (i.e., searching medical records is patient lookup.) Perez at 27:61 - 28:11.) a mobile messaging module, (Perez teaches sending notifications to a user via text message (i.e., mobile messaging). Perez at 47:62 - 48:4. As such, the notification module (Fig. 10) that transmits notifications to a user is a mobile messaging module.) a translation module (Perez teaches a modification engine that indicates if a translation of a message should be made and if it is necessary may perform the translation from one language to another. (i.e., automatically translate the message from one language to another without human interaction.) Perez at 41:40 - 42:2.) and the software middleware layer; (Perez teaches the notification system may be implemented as middleware. Perez at 49:6 - 49:24.).
wherein the translation into the second language is a machine translation by the translation module without human interaction (Perez teaches a modification engine that translates a message from one language to another (i.e., from one language to another) in response to determining that the message should be translated. (i.e., automatic without human interaction.) Perez at 41:40 - 42:2.)
Perez, however, does not teach sending a confirmation prompt message to the user; and receiving a confirmation prompt reply message from the user.
In a similar field of endeavor (e.g., a medical notification system transmitting medical notification messages according to user preferences), Polimeni teaches sending a confirmation prompt message to the user…; and receiving a confirmation prompt reply message from the user…; (Polimeni teaches presenting a confirm or cancel request to the patient (i.e., a confirmation prompt message and receiving a confirmation prompt reply message from the user). Polimeni ¶¶ [0147] - [0148].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez with the teachings of Polimeni to provide sending and receiving a confirmation prompt and reply because of Perez and Polimeni’s significant overlapping fields of endeavor. As such, a person of ordinary skill in the art would have been motivated to provide the additional functionality of Polimeni’s confirmation prompts to Perez’ EMR system because Polimeni also contemplates a an EMR system including confirmation prompts and replies that improves the efficiency of treatment services leading to longer and healthier patient lives. (Polimeni at ¶ [0004].)
Perez in view of Polimeni (hereinafter Perez-Polimeni), however, do not teach wherein the translation module is further configured to provide automatic translation and multi-lingual localization capabilities whereby the service provider can communicate bi-laterally in English and the patient can receive the message in English and 1 non-English language based on the multi-lingual localization preference wherein the confirmation prompt message and the confirmation prompt reply message are configured to be in English and 1 non-English language.
In a similar field of endeavor (e.g., translation of messages to facilitate communication between one or more people), Needham teaches wherein the translation module is further configured to provide automatic translation and multi-lingual localization capabilities whereby the service provider can communicate bi-laterally in English and the patient can receive the message in English and 1 non-English language based on the multi-lingual localization preference wherein the confirmation prompt message and the confirmation prompt reply message are configured to be in English and 1 non-English language. (Needham teaches translating a message into multiple languages comprising English (see Needham, Fig. 4) and at least one non-English language (see Needham, Fig. 4) based on preference information of the user. Needham at ¶¶ [0032] - [0042]. As such, in a communication system employing translation such as Perez, a simple substitution of the translation system of Needham would maintain all the capabilities of Perez' translation while also providing further utility to allow for multi-lingual resulting translations based on user preferences. Therefore, Polimeni's confirmation prompts, in combination with Perez' and Needham's systems would make it obvious to a person of ordinary skill in the art that a translated message can be translated into English and 1 non-English language. Perez at 40:17 - 42:2. and Needham ¶¶ [0032] - [0042].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni with the teachings of Needham to provide automatic translation and multi-lingual localization capabilities whereby the service provider can communicate bi-laterally in English and the patient can receive the message in English and 1 non-English language based on the multi-lingual localization preference wherein the confirmation prompt message and the confirmation prompt reply message are configured to be in English and 1 non-English language. Doing so would have allowed for more fluid communication in mixed language conversations as recognized by Needham at ¶ [0030].
Perez-Polimeni in view of Needham (hereinafter Perez-Polimeni-Needham), however, does not teach “wherein the message is deliverable as a bilingual text or voice message comprising English and the second language, including delivery as a ".wav" voice note; sending a confirmation prompt message to the user as a SMS message; receiving a confirmation prompt reply message from the user as a SMS message; obtaining a delivery receipt and responsive to the delivery receipt, updating a platform record and an EMR patient record and updating an EMR tickler / task message record to confirm that the SMS message requests has been sent and received; and wherein updating the EMR patient record further comprises saving the SMS status in the EMR patent record, thereby providing an update for the care process.”
In a similar field of endeavor (e.g., EMR systems and communications between physicians and patients for medical care), Gaskill teaches wherein the message is deliverable as a bilingual text or voice message comprising English and the second language, including delivery as a ".wav" voice note; (Gaskill teaches sending messages to a user device using a .WAV format. Gaskill at ¶ [0404]. As such, a simple substitution of Gaskill's WAV format messages with Perez's translation then sending of a message between physicians and patients would have been a predictable variation due to their similar fields of endeavor and similar goals.)
sending a confirmation prompt message to the user as a SMS message; receiving a confirmation prompt reply message from the user as a SMS message; (Gaskill teaches sending a message via SMS to a user where the user takes medication then confirms the medication has been taken (i.e., a confirmation prompt and reply via SMS). Gaskill at ¶¶ [0272] - [0273].)
obtaining a delivery receipt and responsive to the delivery receipt, updating a platform record and an EMR patient record and updating an EMR tickler / task message record to confirm that the SMS message requests has been sent and received; (Gaskill teaches sending a confirmatory message to the advance patient management (APM) system that confirms that an SMS was issued by the APM. Gaskill at ¶ [0131]. Further, Gaskill teaches that SMS messages may be stored at an SMSC center until they are forwarded to the user device and the APM is notified that the message was forwarded (i.e., delivery receipt that updates a record/EMR tickler that the SMS message has been sent and received.). Gaskill at ¶¶ [0083] - [0085].)
wherein updating the EMR patient record further comprises saving the SMS status in the EMR patent record, thereby providing an update for the care process. (Gaskill teaches sending SMS reminders to a patient and updating information such as a patients medication schedule and medication inventory in response to the patient confirming that all meds have been taken. (i.e., EMR records are updated by saving the SMS information in the medication schedule/medication inventory.) Gaskill at ¶¶ [0265] - [0270].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham with the teachings of Gaskill to provide the limitations of claim 1. Doing so would have allowed the patient to have increased interaction with various networks and services and would have allowed for more access to medical services as recognized by Gaskill at ¶¶ [0049] – [0050].
Regarding claim 3, Perez-Polimeni-Needham in view of Gaskill (hereinafter Perez-Polimeni-Needham-Gaskill) teaches all the limitations of claim 1 as laid out above. Further, Perez teaches verifying patient data by logging into a patient portal. (Perez teaches a user authenticating themselves to an EMR system (i.e., logging into an online account). Perez at 42:30 – 43:6.)
Regarding claim 5, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Further, Perez teaches the service engine is an online portal. (Perez teaches a web interface (i.e., online portal) as the hub for the EMR service. Perez at 30:1 – 35.)
Regarding claim 6, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Further, Polimeni teaches the option to provide a read receipt to the recipient. (Polimeni teaches storing “notifications” of received messages within the EMR system and indicating that the message has been delivered (i.e., the message appears in the inbox) and read (a read indicator is shown on the message). Polimeni at ¶¶ [0253] – [0268]. Further, theses notifications are stored within the inbox (i.e., read and delivery status are updated and stored upon delivery and reading of the messages.) Polimeni at ¶¶ [0253] – [0268]. As such, the read and delivered information are visible to the user via the web interface (i.e., they have the option to view read receipts.))
Regarding claim 9, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Further, Perez teaches the step of checking the system with records further comprising checking the system data records. (Perez teaches accessing and updating the user’s health records via the EMR system. Perez at 36:15 – 36:50.)
Regarding claim 13, Perez teaches An EMR notification system for providing multi-lingual translation of EMR notification messages to the mobile device of a recipient, the system comprising: (Perez teaches an EMR system sending medical notifications to patients wherein the messages may be translated. Perez at 3:24 – 4:44 and 40:17 – 42:2.)
a computer to create a message; (Perez teaches the EMR system comprising multiple computers used to create and send messages. Perez at 3:24 – 4:44.)
an EMR server in communication with EMR system; (Perez teaches the EMR system comprising a server that contains medical records, (e.g., an EMR server). Perez at 9:53 – 10:21.)
a pharmacy management system (PMS) in communication with EMR system; (Perez teaches the EMR system transaction management system including a pharmacy orders section (i.e., a pharmacy management system). Perez at 21:30 – 22:37.)
a database to store records; (Perez teaches a database comprising medical records. Perez at 24:22 – 25:3.)
an application programming interface (API) connectivity module; (Perez teaches the EMR system including an API. Perez at 39:65 – 40:16.)
a recipient mobile device with one or more supported platforms; (Perez teaches a mobile device receiving messages wherein the EMR system includes multiple platforms like patient portals, doctor portals, mobile apps, widgets, etc. Perez at 19:29 – 19:38.)
a messenger module; (Perez teaches a messaging bus for creating and sending messages between users. (i.e., a messenger module). Perez at 34:48 – 35:19.)
a validation portal; (Perez teaches an authentication engine (i.e., a validation portal). Perez at 40:66 – 41:14.)
a translation engine configured to translate the text messages to another language prior to delivery of the message to the recipient; (Perez teaches translating the message from the original language to a second language (i.e., Russian to English, English to Russian, etc.) Perez at 40:17 - 42:2.)
a software middleware layer configured to connect to one or more EMR systems; (Perez teaches a system for providing medical notifications and information to authorized users that may be implemented as middleware (i.e., middleware connecting one or more EMR systems.) Perez at 3:24 - 4:3 and 49:6 - 49:24.)
and wherein the EMR notification system, in communication with the EMR server is configured to:
receive a message from a sender; (Perez teaches the messaging system includes user devices capable of communicating with the notification service. (i.e., receive messages from a sender.) Perez at 37:57 – 38:26.)
translate the message into another language; (Perez teaches translating the message from the original language to a second language (i.e., Russian to English, English to Russian, etc.) Perez at 40:17 - 42:2.)
send the message on the recipient mobile device; (Perez teaches translating a message between two languages to a patient’s preferred language. Perez at 41:40 - 42:2. As such, the translated message is sent to the user.)
wherein the EMR system is configured to support a plurality EMR connectivity modules, (Perez teaches a plurality of engines (i.e., EMR connectivity modules) implemented withing the system that may be implemented as middleware Perez at 3:24 - 4:3, 49:6 - 49:24, and Fig. 10.) the EMR connectivity modules are selected from a list consisting of a Task Manager, (Perez teaches a transaction management engine operating to manage transmissions of medical-related content (i.e., task manager). Perez at 5:9 - 5:50.) a Patient lookup module, (Perez teaches an analytics and search engine that is used to evaluate which information a user is allowed to query when a user queries medical records/medical information (i.e., searching medical records is patient lookup.) Perez at 27:61 - 28:11.) a mobile messaging module, (Perez teaches sending notifications to a user via text message (i.e., mobile messaging). Perez at 47:62 - 48:4. As such, the notification module (Fig. 10) that transmits notifications to a user is a mobile messaging module.) a translation module (Perez teaches a modification engine that indicates if a translation of a message should be made and if it is necessary may perform the translation from one language to another. (i.e., automatically translate the message from one language to another without human interaction.) Perez at 41:40 - 42:2.) and the software middleware layer; (Perez teaches the notification system may be implemented as middleware. Perez at 49:6 - 49:24.).
Perez, however, does not teach sending a confirmation prompt message to the user; and receiving a confirmation prompt reply message from the user; receive a notification of read and delivery receipt of the message; and update records of the EMR system with translation records and delivery status.
In a similar field of endeavor (e.g., a medical notification system transmitting medical notification messages according to user preferences), Polimeni teaches sending a confirmation prompt message to the user; and receiving a confirmation prompt reply message from the user (Polimeni teaches presenting a confirm or cancel request to the patient (i.e., a confirmation prompt message and receiving a confirmation prompt reply message from the user). Polimeni ¶¶ [0147] - [0148].)
Further, Polimeni teaches [receiving] a notification of read and delivery receipt of the message; and update records of the EMR system with translation records and delivery status. (Polimeni teaches storing “notifications” of received messages within the EMR system and indicating that the message has been delivered (i.e., the message appears in the inbox) and read (a read indicator is shown on the message). Polimeni at ¶¶ [0253] – [0268]. Further, theses notifications are stored within the inbox (i.e., read and delivery status are updated and stored upon delivery and reading of the messages.) Polimeni at ¶¶ [0253] – [0268].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez with the teachings of Polimeni to provide sending and receiving a confirmation prompt and reply as well as receiving read and delivery receipts because of Perez and Polimeni’s significant overlapping fields of endeavor. As such, a person of ordinary skill in the art would have been motivated to provide the additional functionality of Polimeni’s confirmation prompts to Perez’ EMR system because Polimeni also contemplates a an EMR system including confirmation prompts and replies that improves the efficiency of treatment services leading to longer and healthier patient lives. (Polimeni at ¶ [0004].)
Perez-Polimeni, however, do not teach wherein the translation module is further configured to provide automatic translation and multi-lingual localization capabilities whereby the service provider can communicate bi-laterally in English and the patient can receive the message in English and 1 non-English language based on the multi-lingual localization preference wherein the confirmation prompt message and the confirmation prompt reply message are configured to be in English and 1 non-English language.
In a similar field of endeavor (e.g., translation of messages to facilitate communication between one or more people), Needham teaches wherein the translation module is further configured to provide automatic translation and multi-lingual localization capabilities whereby the service provider can communicate bi-laterally in English and the patient can receive the message in English and 1 non-English language based on the multi-lingual localization preference wherein the confirmation prompt message and the confirmation prompt reply message are configured to be in English and 1 non-English language. (Needham teaches translating a message into multiple languages comprising English (see Needham, Fig. 4) and at least one non-English language (see Needham, Fig. 4) based on preference information of the user. Needham at ¶¶ [0032] - [0042]. As such, in a communication system employing translation such as Perez, a simple substitution of the translation system of Needham would maintain all the capabilities of Perez' translation while also providing further utility to allow for multi-lingual resulting translations based on user preferences. Therefore, Polimeni's confirmation prompts, in combination with Perez' and Needham's systems would make it obvious to a person of ordinary skill in the art that a translated message can be translated into English and 1 non-English language. Perez at 40:17 - 42:2. and Needham ¶¶ [0032] - [0042].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni with the teachings of Needham to provide automatic translation and multi-lingual localization capabilities whereby the service provider can communicate bi-laterally in English and the patient can receive the message in English and 1 non-English language based on the multi-lingual localization preference wherein the confirmation prompt message and the confirmation prompt reply message are configured to be in English and 1 non-English language. Doing so would have allowed for more fluid communication in mixed language conversations as recognized by Needham at ¶ [0030].
Perez-Polimeni-Needham, however, does not teach responsive to the delivery receipt, updating a platform record and an EMR patient record and updating an EMR tickler / task message record to confirm that the SMS message requests has been sent and received; and wherein updating the EMR patient record further comprises saving the SMS status in the EMR patent record, thereby providing an update for the care process.
In a similar field of endeavor (e.g., EMR systems and communications between physicians and patients for medical care) responsive to the delivery receipt, updating a platform record and an EMR patient record and updating an EMR tickler / task message record to confirm that the SMS message requests has been sent and received; (Gaskill teaches sending a confirmatory message to the advance patient management (APM) system that confirms that an SMS was issued by the APM. Gaskill at ¶ [0131]. Further, Gaskill teaches that SMS messages may be stored at an SMSC center until they are forwarded to the user device and the APM is notified that the message was forwarded (i.e., delivery receipt that updates a record/EMR tickler that the SMS message has been sent and received.). Gaskill at ¶¶ [0083] - [0085].)
wherein updating the EMR patient record further comprises saving the SMS status in the EMR patent record, thereby providing an update for the care process. (Gaskill teaches sending SMS reminders to a patient and updating information such as a patients medication schedule and medication inventory in response to the patient confirming that all meds have been taken. (i.e., EMR records are updated by saving the SMS information in the medication schedule/medication inventory.) Gaskill at ¶¶ [0265] - [0270].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham with the teachings of Gaskill to provide the limitations of claim 13. Doing so would have allowed the patient to have increased interaction with various networks and services and would have allowed for more access to medical services as recognized by Gaskill at ¶¶ [0049] – [0050].
Regarding claim 14, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 13 as laid out above. Further, Perez teaches wherein the recipient can be patient, physician or clinic staff. (Perez teaches the provide medical data (i.e., notifications and other information) to first responders, medical professionals, patients, or any other suitable user. Perez at 11:49 – 59.)
Regarding claim 15, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 13 as laid out above. Further, Perez teaches the database is configured to store demographics info (Perez teaches storing demographic information of the user. Perez at 40:17 – 40:36.) and further consists of a tickler and task system module. (Perez teaches providing reminder notifications regarding a patient’s treatment or care to medical professionals or authenticated users (such as the patient themselves or trusted caretakers) (i.e., a tickler and task module). Perez at 36:51 – 64.))
Regarding claim 16, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 13 as laid out above. Further, Perez teaches the system of Claim 13 wherein the database selected list consists of a platform record database, a pharmacy database, a language preferences database, a demographics database, and a message recorder database. (Perez teaches a user information database comprising language information, medical records, messaging information demographics, etc. Perez at 40:17 – 40:36. Further, Perez teaches a management engine including pharmacy orders (i.e., pharmacy database). Perez at 21:30 – 22:37.)
Claims 4 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Perez-Polimeni-Needham-Gaskill as applied to claim 1 above, and further in view of U.S. Patent No. 11,636,955 B1 to Peilun Shan et al (hereinafter Shan).
Regarding claim 4, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Perez-Polimeni-Needham-Gaskill does not teach a module for chatbot support. Shan, however, teaches providing technical support using a chat-bot. (Shan teaches a communications management engine supporting chatbot or a human chat interface. (i.e., chatbot support is provided using the chatbot.) Shan at Fig. 4 and 7:21-7:44.)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Shan to provide the method of claim 1 further comprising a module for chat-bot support. Doing so would have improved the usability of the system as recognized by Shan at 7:21-7:44.
Regarding claim 20, Perez-Polimeni-Needham-Gaskill teaches every limitation of claim 13 as laid out above. Perez-Polimeni-Needham, however, do not teach claim 13 further comprising a module for chat-bot support. Shan, however, teaches a module for chatbot support. (Shan teaches a communications management engine supporting chatbot or a human chat interface. (i.e., a module for chatbot support.) Shan at Fig. 4 and 7:21-7:44.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Shan to provide the method of claim 1 further comprising a module for chat-bot support. Doing so would have improved the usability of the system as recognized by Shan at 7:21-7:44.
Claims 11, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Perez-Polimeni-Needham-Gaskill as applied to claims 1 and 13 above, and further in view of U.S. Patent Application Publication No. 2019/0287662 A1 to Alicia Hennie et al. (hereinafter Hennie).
Regarding claim 11, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Perez-Polimeni-Needham, however, do not teach two-factor authentication.
Hennie teaches supporting two-factor authentication (Hennie teaches an EMR system. Hennie at ¶¶ [0077] – [0081]. Further, Hennie teaches performing user authentication using two-factor authentication via SMS. Hennie at ¶ [0087].)
It would have been prima facie obvious to one of ordinary skill in the art to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Hennie to provide the method of claim 1 further comprising support for two-factor authentication. Doing so would have provided a secure communication interface as recognized by Hennie at ¶ [0061]. Further, Perez teaches an authentication engine for providing access to the EMR system by authorized users only, (Perez at 26:25 – 27:4.) as such a person of ordinary skill in the art would have found it obvious to bolster Perez’s authentication with Hennie’s authentication to improve authentication services.
Regarding claim 12, Perez-Polimeni-Needham-Gaskill in view of Hennie teaches claim 11 as laid out above. Further, Hennie teaches the two-factor authentication sending an SMS message to a user for authentication. Hennie at ¶ [0087].
Regarding claim 19, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 13 as laid out above. Perez-Polimeni-Needham-Gaskill however does not teach supporting two-factor authentication configured to receive a SMS message passcode to the user mobile phone.
Hennie teaches supporting two-factor authentication (Hennie teaches an EMR system. Hennie at ¶¶ [0077] – [0081]. Further, Hennie teaches performing user authentication using two-factor authentication via SMS. Hennie at ¶ [0087].)
It would have been prima facie obvious to one of ordinary skill in the art to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Hennie to provide the method of claim 1 further comprising support for two-factor authentication. Doing so would have provided a secure communication interface as recognized by Hennie at ¶ [0061]. Further, Perez teaches an authentication engine for providing access to the EMR system by authorized users only, (Perez at 26:25 – 27:4.) as such a person of ordinary skill in the art would have found it obvious to bolster Perez’s authentication with Hennie’s authentication to improve authentication services.
Claims 2, 7 – 8, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perez-Polimeni-Needham-Gaskill as applied to claim 1 above, and further in view of European Patent Application Publication No. 2,804,407 A1 to Gerhard Kramarz-Von Kohout (hereinafter Kohout).
Regarding claim 2, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Further, Perez-Polimeni-Needham-Gaskill teaches checking the system with records for mobile device support message type; (Perez teaches the messaging system sending notifications using a variety of messaging services including SMS, MMS, or any other suitable messaging service (a person of ordinary skill in the art would have understood that Android and iMessage are popular messaging services and would be suitable for this purpose.) Perez at 38:25 – 38:27.)
check for delivery and read receipt; (Polimeni teaches storing “notifications” of received messages within the EMR system and indicating that the message has been delivered (i.e., the message appears in the inbox) and read (a read indicator is shown on the message). Polimeni at ¶¶ [0253] – [0268]. Further, theses notifications are stored within the inbox (i.e., read and delivery status are updated and stored upon delivery and reading of the messages.) Polimeni at ¶¶ [0253] – [0268].)
if a record is found, determine a mobile device platform; and if the platform is SMS, send a SMS message; (Perez teaches sending the message using SMS, MMS, or any other suitable messaging service after receiving the “address” of the user device (i.e., checking the record for compatibility). Perez at 38:25 – 38:27. As such, a person of ordinary skill in the art would have understood that, in order to send the message using any of these protocols, compatibility would be checked before sending the message.)
obtain a delivery receipt; obtain a reply; (Polimeni teaches storing “notifications” of received messages within the EMR system and indicating that the message has been delivered (i.e., the message appears in the inbox) and read (a read indicator is shown on the message). Polimeni at ¶¶ [0253] – [0268]. Further, theses notifications are stored within the inbox (i.e., read and delivery status are updated and stored upon delivery and reading of the messages.) Polimeni at ¶¶ [0253] – [0268].)
update the EMR record. (Perez teaches updating EMR records based on user data and storing the updates in the medical records such as information regarding what types of alerts/notifications are to be sent to the user. Perez at 27:5 – 27:44)
Perez-Polimeni-Needham, however, do not teach if a record is not found, checking to determine whether the mobile device is an RCS-enabled Android® device; if RCS is not enabled, send using iMessage; if the platform is Android®, send an RCS message; queue the RCS message for further sending if user is offline; if the platform is iOS for iPhone® devices; send using iMessage®; check for delivery and read receipt; obtain a delivery receipt; obtain a read receipt;
In a similar field of endeavor (e.g., transmitting alert messages) Kohout teaches if a record is not found, checking to determine whether the mobile device is an RCS-enabled Android® device; (Kohout teaches sending an emergency alert via RCS, SMS, MMS, or an IP based messaging service such as iMessage or WhatsApp. Kohout at ¶¶ [0020] – [0030])
if RCS is not enabled, send using iMessage*; (Kohout discloses sending the emergency message based on the messaging service. (i.e., if the messaging service is not RCS and is iMessage, then send using iMessage.) Kohout at ¶¶ [0020] – [0030].)
if the platform is Android®, send an RCS message; (Kohout discloses sending an emergency message in a variety of methods including RCS based on the messaging service. (i.e., if the messaging service is RCS (e.g., on an android device) then send the message via RCS). Kohout at ¶¶ [0020] – [0030].)
if the platform is iOS for iPhone® devices; (Kohout discloses sending an emergency message via an IP based messaging service (such as iMessage) based on the messaging service. (i.e., if the messaging service is iMessage (e.g., on an iPhone platform) send the message via iMessage.) Kohout at ¶¶ [0020] – [0030].)
send using iMessage®; (Kohout discloses sending an emergency alert using iMessage. Kohout at ¶¶ [0020] – [0030].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Kohout to provide the method of claim 1 further comprising the limitations of claim 2. Doing so would have improved transmission of messages to recipient by allowing the messages to reach the user or subscriber quickly and efficiently as recognized by Kohout in ¶¶ [0020] – [0030]. Further, Perez contemplates using any form of messaging service for sending notifications, as such, a person of ordinary skill in the art would have understood that RCS and iMessage would have been suitable messaging services and would have been motivated to combine Kohout with Perez-Polimeni-Needham-Gaskill to provide the limitations of claim 2.
Regarding claim 7, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Further, Perez teaches the mobile platform is selected from a list including SMS and email. (Perez teaches sending a message using SMS, MMS, or any other messaging service. Perez at 38:30 – 38:67) Perez-Polimeni-Needham, however, does not teach the list including iOS, Android, or RCS.
Kohout teaches the mobile platform is selected from a list consisting of android, RCS, iOS, SMS, and email. (Kohout teaches sending an emergency message on a messaging service selected from a list of messaging services such as iMessage, RCS, MMS, SMS, email, etc. (i.e., sending the message on a variety of platforms including RCS (RCS and Android), iMessage (iOS), SMS, email, and MMS.) Kohout at ¶¶ [0020] – [0030].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Kohout to provide the method of claim 1 further comprising the limitations of claim 7. Doing so would have improved transmission of messages to recipient by allowing the messages to reach the user or subscriber quickly and efficiently as recognized by Kohout in ¶¶ [0020] – [0030].
Regarding claim 8, Perez-Polimeni-Needham-Kohout teaches all the limitations of claim 2 as laid out above. Further Perez teaches the message type being selected from a list consisting of SMS and email. (Perez teaches it may be SMS, MMS, email or other forms of messaging. Perez at 45:1 – 9.) Perez does not teach the list comprising iMessage or RCS, however Perez contemplates any suitable messaging service (RCS and iMessage are both suitable messaging services).
Kohout, however, teaches the message type is selected from a list consisting of iMessage, RCS, SMS and email. (Kohout teaches an emergency message being sent via iMessage, RCS, SMS, MMS, email, or other services. Kohout at ¶¶ [0020] – [0030].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Kohout to provide the method of claim 2 further comprising the limitations of claim 8. Doing so would have improved transmission of messages to recipient by allowing the messages to reach the user or subscriber quickly and efficiently as recognized by Kohout in ¶¶ [0020] – [0030].
Regarding claim 17, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 13 as laid out above. Perez-Polimeni-Needham-Gaskill however, does not teach the messenger module is selected from a list consisting of iMessage module, an RCS Android module and an SMS module.
Kohout, however, teaches the messenger module is selected from a list consisting of iMessage module, an RCS Android module and an SMS module. (Kohout teaches an emergency message being sent via iMessage, RCS, SMS, MMS, email, or other services. Kohout at ¶¶ [0020] – [0030].)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Kohout to provide the method of claim 13 further comprising the limitations of claim 17. Doing so would have improved transmission of messages to recipient by allowing the messages to reach the user or subscriber quickly and efficiently as recognized by Kohout in ¶¶ [0020] – [0030].
Claims 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Perez-Polimeni-Needham-Gaskill as applied to claim 1 above, and further in view of U.S. Patent No. 11,783,922 B1 to Siu Tong et al. (hereinafter Tong)
Regarding claim 10, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 1 as laid out above. Perez-Polimeni-Needham-Gaskill does not teach the communication with the EMR system and service engine is conducted using FIHR APIs, REST APIs and other connectivity APIs.
Tong, however, teaches the communication with the EMR system and service engine is conducted using FIHR APIs, REST APIs and other connectivity APIs. (Tong teaches a method of data interchange for healthcare systems that uses both FIHR, REST, and other APIs. Tong at 15:46 – 15:52, and 18:24 – 18:30.)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Tong to provide the method of claim 1 wherein the communication with the EMR system and service engine is conducted suing FIHR APIs, REST APIs, and other connectivity APIs. Doing so would have improved care and reduced costs as recognized by Tong at 7:52 - 7:62, 9:7 - 9:41, and 9:59 - 10:7.
Regarding claim 18, Perez-Polimeni-Needham-Gaskill teaches all the limitations of claim 13 as laid out above. Perez-Polimeni-Needham, does not teach the application programming interface (API) connectivity module further comprises FIHR API, REST APIs and other API connections.
Tong, however, teaches the application programming interface (API) connectivity module further comprises FIHR API, REST APIs and other API connections. (Tong teaches a method of data interchange for healthcare systems that uses both FIHR, REST, and other APIs. Tong at 15:46 – 15:52, and 18:24 – 18:30.)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Perez-Polimeni-Needham-Gaskill with the teachings of Tong to provide the method of claim 13 wherein the application programming interface (API) connectivity module further comprises FIHR API, REST APIs and other API connections. Doing so would have improved care and reduced costs as recognized by Tong at 7:52 - 7:62, 9:7 - 9:41, and 9:59 - 10:7.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAMERON KENNETH YOUNG whose telephone number is (703)756-1527. The examiner can normally be reached Mon - Fri, 9:00 AM - 5:00 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, Andrew Flanders can be reached at 571-272-7516. 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.
/CAMERON KENNETH YOUNG/Examiner, Art Unit 2655
/ANDREW C FLANDERS/Supervisory Patent Examiner, Art Unit 2655