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 .
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 31 December 2025 has been entered. Applicant amended claims 1, 7, 10, 16 and 19. Accordingly, claims 1, 3-10, and 12-19 remain pending.
Response to Arguments
Applicant's arguments filed 31 December 2025 have been fully considered but they are not persuasive.
Applicant’s argument 1:
Even assuming, arguendo, that the ESP in Katz initiates the emergency communication protocol, Katz does not teach or suggest that "the third computing device is unable to initiate the emergency communication protocol" (emphasis added), as required by claim 1 both prior and subsequent to current amendment. Applicant notes the Examiner's own characterization (see Advisory Action, continuation sheet) acknowledges that the ESP's action occurs "as a result of receiving an alert (from a trigger device, or third computing device)" (emphasis added). This appears to presuppose that the third computing device in Katz is in fact able to, and capable of, initiating the emergency communication process in some manner.
Examiner’s remarks:
Paragraph 355 of Katz reveals an elderly patient, John, initiates an alert via his smart watch, which can be the triggering device, that he has fallen. The smartphone/third computing device is out of the elderly patient John reach. Therefore, the third computing device is unable to initiate the emergency communication protocol because the phone is not in the patient reached to initiate the emergency. The main emergency flow calls the elderly patient smart phone and bridges the call with an operator for the nursing home. Although the smartphone is out of John's reach, it is paired with John's smartwatch via Bluetooth. John is able to answer the call by pressing a button on his smartwatch. The operator asks John the nature of his medical emergency, and John indicates that he has fallen and cannot get up. The emergency flow script provides an interactive element that bridges the communication session with a local public safety answering point when the operator interacts with the interactive element. The operator realizes that John needs urgent medical attention and presses the interactive element. This activates a building block in the emergency flow script that calls the PSAP and bridges the call with the communication session between the nursing home operator and John (e.g., creating a conference call including the PSAP dispatcher, nursing home operator, and John).
Applicant’s argument 2:
A server receiving an alert from a triggering device including, for example: a list of associated devices of a triggering device, emergency flow identifiers, user identifiers, and identification numbers for emergency flow building blocks is not the same as, and does not teach or suggest, extracting from the server data items to be exchanged including "a username associated with one or more of the destination computing devices" (emphasis added) that are then transmitted to destination devices - as required in claim 1 as amended.
Examiner’s remarks:
Paragraph 9 of Katz recites the user identifier is a username. The claim fails to disclose how the username is associated with one or more destination computing device. Therefore, a user name connected/linked to other devices via the registration in the emergency management system is associated with destination devices (emergency contacts, organizational contacts, institution, personal or professional service providers, etc., ).
Paragraph 202 of Katz also recites the information regarding the selected emergency flow includes user names, contact names, and associated accounts (e.g., phone numbers, email accounts). In some embodiments, after an emergency flow is selected, the Emergency Console displays data pertaining to the selected emergency flow. For example, in some embodiments, the Emergency Console displays an emergency flow history including an entry for every individual execution of the selected emergency flow. Recall, per paragraph 99 of Katz, the emergency flow is initiated/executed by EFMS. Once the EFMS receives an emergency alert (e.g., an API call generated by an emergency trigger script integrated into a computer program on a triggering device), the EFMS then executes an emergency flow associated with the emergency alert (e.g., an emergency flow associated with the emergency trigger script or any data included in the emergency alert).
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, 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.
Claim(s) 1, 3-10, and 12-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Katz et al US 20230410635 (hereinafter Katz) in view of Martin et al US 20230370540 (hereinafter Martin).
As to claim 1, Katz teaches a computerized method for performing exchanges of data over a computer network (abstract and paragraph 19 disclose systems, devices, methods, and media for connecting a user for providing emergency assistance based on emergency alerts from triggering devices that gather emergency information from one or more devices in computer network (mesh network, local network)), the method comprising, by a server comprising a computer processor (paragraph 51 discloses emergency management system that comprises a server. The server comprises a processor and memory):
extracting from the server, by the processor (paragraph 51 discloses an emergency management system (EMS) that comprises servers 148/128/109. The server comprises a processor and memory), one or more data items to be exchanged based on one or more first information items , wherein one or more of the first information items are transmitted from a sender computing device, thereby initiating an emergency communication protocol by the sender computing device (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call [ from a trigger device], the ESP transmits an emergency flow/communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. Paragraphs 273-274 disclose the EMS receives an emergency communication associated with the emergency from the ESP. The EMS can then process the emergency communication and any emergency data included therein and determine one or more recipients to notify of the emergency or share the emergency data with or determine one or more actions to take based on the emergency communication and emergency data. The EMS[server] extracts and can transmit the location data/one or more data items), the transmitting of one or more of the first information items triggered by [software application] receiving input from the sender computing device, wherein the [software application] is integrated into an application deployed on the server (paragraph 120 discloses emergency console allows a variety of customizable emergency flows between users, emergency contacts, emergency services, and related third parties by establishing a multitude of voice and data connections to Public Safety Answering Points (PSAPs) through a variety of trigger mechanisms the Emergency Console is operated on an emergency response server. In some embodiments, the EMS comprises an emergency response server. In some embodiments, the Emergency Console is a web interface that provides tools for generating and testing emergency flows. The Emergency Console allows for emergency flows to be initiated via simple API triggers from any device. Paragraph 275 reveals the ESP transmit the emergency communication to the EMS, when the ESP receives an emergency call, sending the emergency communication that comprises the first information in the form of a notification/input informing the EMS of the emergency call. The emergency notification may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. In some embodiments, the emergency communication is an API call received through an API (application programming interface) provided by the EMS . In some embodiments, the emergency communication is generated and transmitted to the EMS through an emergency response application executed on a computing device at the ESP. The EMS received the data from the ESP to execute emergency flows, notification procedure);
determining, by the processor (paragraph 51 discloses an emergency management system that comprises a server. The server comprises a processor and memory), a mode of communication selected from a group consisting of short message service (SMS), telephone call and email (paragraphs 58 and 107 disclose the EFMS employs service actions to execute various emergency flows that requires transmitting data and communications to and from various users and output services using various mediums and communication modes such as SMS, MMS, voice call, text messages, see also Paragraphs 99 and 107), the determining based on: one or more of the first information items transmitted from the sender computing device (see claim limitation above citing paragraphs 273 and 275 ), and a plurality of second information items stored at the server, wherein one or more of the second information items describe one or more destination computing devices (paragraphs 86 and 107 disclose the emergency alert is sent via a cellular connection to the emergency flow management system which initiates an emergency flow script and an emergency call and a two way communication link may be established. Communication link is used for sending data such as user data, location data, emergency data, text, images, and video from the triggering device. Paragraph 92 further discloses the emergency alert comprises list of contacts and emergency location to the EFMS. The EFMS executes the emergency flow comprising a mode of communication of a call contact to confirm emergency, repeat with second contact if no response with first contact, and connecting to appropriate emergency service provider such as public safety answering point (PSAP) based on the provided location. Paragraphs 99 and 107 further disclose the EFMS receives the emergency alert and execute an emergency flow associated with the alert. The emergency flow involves determining a mode of communication based on the emergency flow ID, location data, and/or user data (contact information) sent by the ESP device, which involve mode of communication of contacting the triggering device for more information, another device for confirmation of the emergency, a nurse and/or calling 911 via SMS, MMS, text message, internet enabled communication service such as WhatsApp, Slack, Facebook Messenger via an API call or HTTP post, voice call(PSTN data or VoIP call), TTS message, or text to speech message communication. Therefore, the second information may involve contact information and location data), wherein one or more of the data items to be exchanged includes a username associated with one or more of the destination computing devices (paragraph 53 discloses the server of the emergency management system (EMS) receive/extract an emergency alert that is transmitted from triggering device. The emergency alert is the data item that comprises first information items of a list of at least one associated device of the triggering device. Paragraphs 274 and 303-304 also disclose an emergency alert that comprises location data. Paragraphs 4, 16, 19-20, and 97-98 further disclose the emergency alert also comprise an emergency flow identifier, user identifier, and additional data such as location data. Paragraphs 20 and 69 reveal emergency data includes user identifier, location data, medical data, personal information, and contact information; paragraph 9 recites the user identifier is a username. A user name connected/linked to other devices via the emergency management system is associated with destination devices (emergency contacts, organizational contacts, institution, personal or professional service providers, etc., ). Paragraph 202 also recites the information regarding the selected emergency flow includes user names, contact names, and associated accounts (e.g., phone numbers, email accounts). Recall, per paragraph 99, the emergency flow is initiated/executed by EFMS. Once the EFMS receives an emergency alert (e.g., an API call generated by an emergency trigger script integrated into a computer program on a triggering device), the EFMS then executes an emergency flow associated with the emergency alert (e.g., an emergency flow associated with the emergency trigger script or any data included in the emergency alert)), wherein the extracted data items and one or more of the second information items were originally retrieved from a third computing device (paragraphs 14, 81, and 331-332 disclose the account is registered by the user to include a list of contact information for the user such as, for example, a list of associated devices. Examples of contact information on an account include phone number, email address, home address, work address, emergency contacts (e.g., name, phone number, email, etc.), and associated devices/destination devices (e.g., other communication devices of the user aside from the device or triggering device sending an emergency alert), the third computing device separate from the sender computing device and from the server (paragraphs 273-274 and 331-332 reveal the third computing device is a mobile device or device of the user and is separate from the EMS server/processor and the ESP devices), wherein an emergency is occurring for the third computing device at a time of the transmitting of one or more of the first information items from the sender computing device (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day), wherein the third computing device is unable to initiate the emergency communication protocol (paragraph 355 reveals the smart watch is the triggering device initialing an alert by an elderly patient, John, has fallen. The smartphone/third computing device is out of the elderly patient reach. Therefore, the third computing device is unable to initiate the emergency communication protocol because the phone is not in the patient reached to initiate the emergency), wherein the extracted data items describe the emergency (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[ from a third computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day), and wherein the extracted data items are received from the third computing device upon registering to the application deployed on the server (paragraphs 14, 81, and 331-332 disclose the account is registered on the EMS by the user using the mobile application or web application to include a list of contact information for the user such as, for example, a list of associated devices. Examples of contact information on an account include phone number, email address, home address, work address, emergency contacts (e.g., name, phone number, email, etc.), and associated devices/destination devices (e.g., other communication devices of the user aside from the device or triggering device sending an emergency alert) , and wherein the one or more first information items transmitted from the sender computing device comprise an identifier of the third computing device (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[ from a third computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller);
transmitting, by the processor (paragraph 51 discloses an emergency management system that comprises a server. The server comprises a processor and memory), the extracted data items to one or more of the destination computing devices based on the determined mode of communication, the transmitted data items comprising an alert message (Paragraphs 273-274 and 287 disclose after the EMS receives an emergency communication associated with the emergency from the ESP, the EMS process the emergency communication and any emergency data included therein and determine one or more recipients (destination computing devices) to notify of the emergency or share the emergency data with or determine one or more actions to take based on the emergency communication and emergency data. The destination computing devices include emergency contacts, organizational contacts, institutions, personal and professional service providers (PSPs), and other ESPs. Paragraph 120 discloses emergency console allows a variety of customizable emergency flows between users, emergency contacts, emergency services, and related third parties by establishing a multitude of voice and data connections to Public Safety Answering Points (PSAPs) through a variety of trigger mechanisms the Emergency Console is operated on an emergency response server. In some embodiments, the EMS comprises an emergency response server. Paragraph 275 reveals the ESP transmit the emergency communication to the EMS, when the ESP receives an emergency call, sending the emergency communication that comprises the first information in the form of a notification/input informing the EMS of the emergency call. The emergency notification may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. In some embodiments, the emergency communication is an API call received through an API (application programming interface) provided by the EMS . In some embodiments, the emergency communication is generated and transmitted to the EMS through an emergency response application executed on a computing device at the ESP. The EMS received the data from the ESP to execute emergency flows, notification procedure);
granting the sender computing device access to one or more records describing the third computing device, the one or more records stored at the server, wherein the granting of the access is based on a location of the third computing device, wherein the granting of the access to the one or more records describing the third computing device is performed while private records of the third computing device are inaccessible to the sender computing device, the private records of the third computing device stored by the server (paragraph 69 discloses the EMS server grants access to records of the third computing device/user mobile device to the sender computing devices (sender devices listed above). The records are stored in the EMS databases. The EMS grants access to the destination devices of data records that are pertinent for the emergency and requested by the ESP. Therefore, data records that are not pertinent will not be delivered/transmitted). Paragraph 81 also reveals setting up registration for the devices (triggering device data and third computing/communication device data) that include emergency contact data, location data, user data. The data is saved in the database of the EMS or third party servers and the data is protected by password, authentication protocols for transmissions. Therefore, certain data of the third computing device will not be accessible as a result of password protection, authentication protocols for transmissions. Paragraph 304 also reveals an ESP provides consent for the EMS to share data generated by the ESP by selecting access controls presented within the GIU), the private records of the third computing device stored by the server (see mapping above, wherein paragraphs 69 and 81 reveal the EMS has clearing house storage/database for storing emergency data, location data, and additional data that is sent by communication devices (triggering devices ) and retrieved by various member devices/recipients). Paragraphs 9 and 295 disclose the user/triggering device is in a data sharing group. The data sharing comprising the one or more contacts linked to one or more member devices (including the trigger device). In some embodiments, the user has authorized location sharing with the one or more member devices associated with the one or more emergency contacts during the emergency. In some embodiments, the method further comprises obtaining a location of the user/(location of the triggering device, sensor device/third computing device) and sharing the location with one or more member devices authorized for location sharing according to the personalized notification procedure) ; and
displaying one or more of the records to which access was granted on a graphical user interface (GUI) of the sender computing device (paragraph 303 reveals displaying access controls to the asset within a GUI. Paragraph 70 discloses the trigger device has a notification module for displaying communications from the EFMS to the user (paragraph 20 discloses using the set of emergency data to determine a notification procedure/electronic communication to be executed/sent, and executing the notification procedure to one or more recipients. Paragraph 69 discloses the emergency data can be retrieved/transmitted and/or distributed to recipients (this may include triggering device/communication device, and/or emergency personnel device). See also paragraph 283).
Katz does not teach that the [software application] which is integrated into an application deployed on the server and used by the triggering/communication device is an artificial intelligence chat-bot.
Martin discloses that the [software application] which is integrated into an application deployed on the server and used by the triggering/communication device is an artificial intelligence chat-bot (paragraphs 82, 101, and 146 disclose an autonomous communication session via an artificial conversational entity(chatbot). The autonomous communication session may be held using different types of electronic devices and different interfaces of electronic devices).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Katz’s software application with the artificial conversational entity(chatbot) as taught by Martin such that the emergency management system can further gather emergency data or information regarding the emergency and deliver safety recommendations to one or more persons potentially affected by the emergency (paragraph 101 of Martin).
As to claim 3, the combination of Katz in view of Martin teaches wherein the determining of a mode of communication and the transmitting of the extracted data items are performed based on an exchange type, wherein the exchange type is generated using a GUI of an administrator device (Katz: paragraphs 102 and 113 reveal elements of the emergency flow are selected/configured or inputted by an administrator via the GUI. The execution of the emergency flow involves initiating communications with an output service such as EDC and PSAP. Accordingly, to paragraphs 116-118, the emergency flow is an exchange type (defined by emergency flow building blocks, which is defined by a script, see paragraph 106) that is configured to execute the communication type (interactive call to the trigger device , call to the customer service provider, bridge calls, or call PSAP) and transmit necessary components of the emergency alert (that includes the emergency data and additional data). Paragraph 125 further reveals the emergency flow scripts may be chosen based on additional user data. Paragraphs 126-140 further reveal a create emergency bridge block that is included in every emergency flow building block. The create emergency bridge block instructs the EFMS to create a communication bridge/communication type based on the emergency alert).
As to claim 4, the combination of Katz in view of Martin teaches comprising displaying one or more of the second information items on the graphical user interface (GUI) of the sender computing device (Katz: paragraph 303 reveals displaying access controls to the asset within a GUI. Paragraph 70 discloses the trigger device has a notification module for displaying communications from the EFMS to the user (paragraph 20 discloses using the set of emergency data to determine a notification procedure/electronic communication to be executed/sent, and executing the notification procedure to one or more recipients. Paragraph 69 discloses the emergency data can be retrieved/transmitted and/or distributed to recipients (this may include triggering device/communication device, and/or emergency personnel device). Paragraphs 69 and 81 reveal the EMS has clearing house storage/database for storing emergency data, location data, and additional data that is sent by communication devices (triggering devices ) and retrieved by various member devices/recipients). Paragraphs 9 and 295 disclose the user/triggering device is in a data sharing group. The data sharing comprising the one or more contacts linked to one or more member devices (including the trigger device). In some embodiments, the user has authorized location sharing with the one or more member devices associated with the one or more emergency contacts during the emergency. In some embodiments, the method further comprises obtaining a location of the user/(location of the triggering device, sensor device/third computing device) and sharing the location with one or more member devices authorized for location sharing according to the personalized notification procedure. In some embodiments, the location of the user is determined using location services for an electronic device associated with the user. In some embodiments, one or more emergency contacts of the user are authorized to receive additional data comprising images, video feed, sensor data, or ESP or response data during an emergency. In some embodiments, the one or more contacts comprise an emergency contact associated with the user identifier, or an organizational contact associated with the user identifier, or both).
As to claim 5, the combination of Katz in view of Martin teaches wherein the exchange type comprises one or more of: an array data structure, a dictionary, and a tree data structure (Katz: paragraphs 102 and 105-106 and 113 reveal elements of the emergency flow are selected/configured or inputted by an administrator via the GUI. Accordingly, to paragraphs 116-118, the emergency flow is an exchange type (defined by emergency flow building blocks, which is defined by a script, see paragraph 106. An array is a fundamental data structure that is used in scripting and programming to store ordered collections of elements. Furthermore, paragraph 142 discloses an emergency flow may be considered as a logic tree which can be a tree data structure) that is configured to execute the communication type (interactive call to the trigger device , call to the customer service provider, bridge calls, or call PSAP) and transmit necessary components of the emergency alert (that includes the emergency data and additional data)).
As to claim 6, the combination of Katz in view of Martin teaches wherein one or more of the destination computing devices device are associated with emergency contacts, and wherein one or more of the destination computing devices device are associated with medical care providers (Katz: paragraphs 58 and 273 disclose the EMS transmits the emergency alert data to an emergency service provider (which can be a first responder) based on the determined mode of communication, PSAP. (Recall, paragraph 92 above which discloses the emergency alert comprises list of contacts and emergency location to the EFMS. The EFMS executes the emergency flow comprising a mode of communication of a call contact to confirm the emergency, repeat with second contact if no response with first contact, and connecting to appropriate emergency service provider such as public safety answering point (PSAP) based on the provided location. Paragraphs 99 and 107 further disclose the EFMS receives the emergency alert and execute an emergency flow associated with the alert. The emergency flow involves determining a mode of communication based on the emergency flow ID, location data, and/or user data (contact information) sent by the triggering device, which involve mode of communication of contacting the triggering device for more information, another device for confirmation of the emergency, a nurse and/or calling 911 via SMS, MMS, text message, internet enabled communication service such as WhatsApp, Slack, Facebook Messenger via an API call or HTTP post, voice call(PSTN data or VoIP call), TTS message, or text to speech message communication).
As to claim 7, the combination of Katz in view of Martin teaches wherein one or more of the data items to be exchanged includes: a health record, a blood type (Katz: paragraph 53 discloses the server of the emergency management system (EMS) receive/extract an emergency alert that is transmitted from triggering device. The emergency alert is the data item that comprises first information items of a list of at least one associated device of the triggering device. Paragraphs 274 and 303-304 also disclose an emergency alert that comprises location data. Paragraphs 4, 16, 19-20, and 97-98 further disclose the emergency alert also comprise an emergency flow identifier, user identifier, and additional data such as location data. Paragraphs 20 and 69 reveal emergency data includes user identifier, location data, medical data, personal information, and contact information).
As to claim 8, the combination of Katz in view of Martin teaches wherein the transmitting of the extracted data items is initiated by clicking a button on the GUI of the sender device (Katz: paragraph 82 discloses the emergency is triggered/transmitted by user input such as the user interacting with the user interface of the triggering device. In some embodiments, the user presses one or more hard or soft buttons on the user interface).
As to claim 9, the combination of Katz in view of Martin teaches comprising automatically performing one or more computer operations by one or more of the destination computing devices based on one or more of the transmitted data items (Katz: paragraphs 58 and 275 disclose the destination computing devices ESP transmits a request for emergency data regarding the emergency, see also paragraph 305 wherein the ESP can activate a drone to receive a defibrillator. Paragraph 58 also reveals the request can be sent autonomously. Martin: paragraph 92 also discloses delivering a safety recommendations via the chat-box from the EMS once 911 call is made based on the emergency alert and data received by the sending computing device). Motivation is similar to the motivation presented in claim 1.
As to claim 10, Katz teaches a computerized system for performing exchanges of data over a computer network (abstract and paragraph 19 disclose systems, devices, methods, and media for connecting a user for providing emergency assistance based on emergency alerts from triggering devices that gather emergency information from one or more devices in computer network (mesh network, local network)), the system comprising: a computerized server comprising a processor and a memory (paragraph 51 discloses emergency management system that comprises a server. The server comprises a processor and memory), wherein the processor (see paragraph 51) is to:
extract from the server (paragraph 51 discloses an emergency management system that comprises servers 148/128/109. The server comprises a processor and memory) one or more data items to be exchanged based on one or more first information items, wherein one or more of the first information items are transmitted from a sender computing device, thereby initiating an emergency communication protocol by the sender computing device (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[ from a trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. Paragraphs 273-274 disclose the EMS receives an emergency communication associated with the emergency from the ESP. The EMS can then process the emergency communication and any emergency data included therein and determine one or more recipients to notify of the emergency or share the emergency data with or determine one or more actions to take based on the emergency communication and emergency data. The EMS[server] extracts and can transmit the location data/one or more data items), the transmitting of one or more of the first information items triggered by [software application] receiving input from the sender computing device, wherein the [software application] is integrated into an application deployed on the server (paragraph 120 discloses emergency console allows a variety of customizable emergency flows between users, emergency contacts, emergency services, and related third parties by establishing a multitude of voice and data connections to Public Safety Answering Points (PSAPs) through a variety of trigger mechanisms the Emergency Console is operated on an emergency response server. In some embodiments, the EMS comprises an emergency response server. In some embodiments, the Emergency Console is a web interface that provides tools for generating and testing emergency flows. The Emergency Console allows for emergency flows to be initiated via simple API triggers from any device. Paragraph 275 reveals the ESP transmit the emergency communication to the EMS, when the ESP receives an emergency call, sending the emergency communication that comprises the first information in the form of a notification/input informing the EMS of the emergency call. The emergency notification may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. In some embodiments, the emergency communication is an API call received through an API (application programming interface) provided by the EMS . In some embodiments, the emergency communication is generated and transmitted to the EMS through an emergency response application executed on a computing device at the ESP. The EMS received the data from the ESP to execute emergency flows, notification procedure);
determine a mode of communication selected from a group consisting of short message service (SMS), telephone call and email (paragraphs 58 and 107 disclose the EFMS employs service actions to execute various emergency flows that requires transmitting data and communications to and from various users and output services using various mediums and communication modes such as SMS, MMS, voice call, text messages, see also Paragraphs 99 and 107), the determining based on: one or more of the first information items transmitted from the sender computing device (see claim limitation above citing paragraphs 273 and 275 ), and a plurality of second information items stored at the server, wherein one or more of the second information items describe one or more destination computing devices (paragraphs 86 and 107 disclose the emergency alert is sent via a cellular connection to the emergency flow management system which initiates an emergency flow script and an emergency call and a two way communication link may be established. Communication link is used for sending data such as user data, location data, emergency data, text, images, and video from the triggering device. Paragraph 92 further discloses the emergency alert comprises list of contacts and emergency location to the EFMS. The EFMS executes the emergency flow comprising a mode of communication of a call contact to confirm emergency, repeat with second contact if no response with first contact, and connecting to appropriate emergency service provider such as public safety answering point (PSAP) based on the provided location. Paragraphs 99 and 107 further disclose the EFMS receives the emergency alert and execute an emergency flow associated with the alert. The emergency flow involves determining a mode of communication based on the emergency flow ID, location data, and/or user data (contact information) sent by the ESP device, which involve mode of communication of contacting the triggering device for more information, another device for confirmation of the emergency, a nurse and/or calling 911 via SMS, MMS, text message, internet enabled communication service such as WhatsApp, Slack, Facebook Messenger via an API call or HTTP post, voice call(PSTN data or VoIP call), TTS message, or text to speech message communication. Therefore, the second information may involve contact information and location data), wherein one or more of the data items to be exchanged includes a username associated with one or more of the destination computing devices (paragraph 53 discloses the server of the emergency management system (EMS) receive/extract an emergency alert that is transmitted from triggering device. The emergency alert is the data item that comprises first information items of a list of at least one associated device of the triggering device. Paragraphs 274 and 303-304 also disclose an emergency alert that comprises location data. Paragraphs 4, 16, 19-20, and 97-98 further disclose the emergency alert also comprise an emergency flow identifier, user identifier, and additional data such as location data. Paragraphs 20 and 69 reveal emergency data includes user identifier, location data, medical data, personal information, and contact information; paragraph 9 recites the user identifier is a username. A user name connected/linked to other devices via the emergency management system is associated with destination devices (emergency contacts, organizational contacts, institution, personal or professional service providers, etc., ). Paragraph 202 also recites the information regarding the selected emergency flow includes user names, contact names, and associated accounts (e.g., phone numbers, email accounts). Recall, per paragraph 99, the emergency flow is initiated/executed by EFMS. Once the EFMS receives an emergency alert (e.g., an API call generated by an emergency trigger script integrated into a computer program on a triggering device), the EFMS then executes an emergency flow associated with the emergency alert (e.g., an emergency flow associated with the emergency trigger script or any data included in the emergency alert)), wherein the extracted data items and one or more of the second information items were originally retrieved from a third computing device (paragraphs 14, 81, and 331-332 disclose the account is registered by the user to include a list of contact information for the user such as, for example, a list of associated devices. Examples of contact information on an account include phone number, email address, home address, work address, emergency contacts (e.g., name, phone number, email, etc.), and associated devices/destination devices (e.g., other communication devices of the user aside from the device or triggering device sending an emergency alert), the third computing device separate from the sender computing device and from the server (paragraphs 273-274 and 331-332 reveal the third computing device is a mobile device or device of the user and is separate from the EMS server/processor and the ESP devices), wherein an emergency is occurring for the third computing device is at a time of the transmitting of one or more of the first information items from the sender computing device, wherein the extracted data items describe the emergency (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[ from a third computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day), wherein the third computing device is unable to initiate the emergency communication protocol (paragraph 355 reveals the smart watch is the triggering device initialing an alert by an elderly patient, John, has fallen. The smartphone/third computing device is out of the elderly patient reach. Therefore, the third computing device is unable to initiate the emergency communication protocol because the phone is not in the patient reached to initiate the emergency), and wherein the extracted data items are received from the third computing device upon registering to the application deployed on the server (paragraphs 14, 81, and 331-332 disclose the account is registered on the EMS by the user using the mobile application or web application to include a list of contact information for the user such as, for example, a list of associated devices. Examples of contact information on an account include phone number, email address, home address, work address, emergency contacts (e.g., name, phone number, email, etc.), and associated devices/destination devices (e.g., other communication devices of the user aside from the device or triggering device sending an emergency alert), and wherein the one or more first information items received from the sender computing device comprise an identifier of the third computing device (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[ from a third computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller);
transmit the extracted data items to one or more of the destination computing devices based on the determined mode of communication, the transmitted data items comprising an alert message (Paragraphs 273-274 and 287 disclose after the EMS receives an emergency communication associated with the emergency from the ESP, the EMS process the emergency communication and any emergency data included therein and determine one or more recipients (destination computing devices) to notify of the emergency or share the emergency data with or determine one or more actions to take based on the emergency communication and emergency data. The destination computing devices include emergency contacts, organizational contacts, institutions, personal and professional service providers (PSPs), and other ESPs. Paragraph 120 discloses emergency console allows a variety of customizable emergency flows between users, emergency contacts, emergency services, and related third parties by establishing a multitude of voice and data connections to Public Safety Answering Points (PSAPs) through a variety of trigger mechanisms the Emergency Console is operated on an emergency response server. In some embodiments, the EMS comprises an emergency response server. Paragraph 275 reveals the ESP transmit the emergency communication to the EMS, when the ESP receives an emergency call, sending the emergency communication that comprises the first information in the form of a notification/input informing the EMS of the emergency call. The emergency notification may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. In some embodiments, the emergency communication is an API call received through an API (application programming interface) provided by the EMS . In some embodiments, the emergency communication is generated and transmitted to the EMS through an emergency response application executed on a computing device at the ESP. The EMS received the data from the ESP to execute emergency flows, notification procedure);
grant the sender computing device access to one or more records describing the third computing device, the one or more records stored at the server, wherein the granting of the access is based on a location of the third computing device, wherein the granting of the access to the one or more records describing the third computing device is performed while private records of the third computing device are inaccessible to the sender computing device, the private records of the third computing device stored by the server (paragraph 69 discloses the EMS server grants access to records of the third computing device/user mobile device to the sender computing devices (sender devices listed above). The records are stored in the EMS databases. The EMS grants access to the destination devices of data records that are pertinent for the emergency and requested by the ESP. Therefore, data records that are not pertinent will not be delivered/transmitted). Paragraph 81 also reveals setting up registration for the devices (triggering device data and third computing/communication device data) that include emergency contact data, location data, user data. The data is saved in the database of the EMS or third party servers and the data is protected by password, authentication protocols for transmissions. Therefore, certain data of the third computing device will not be accessible as a result of password protection, authentication protocols for transmissions. Paragraph 304 also reveals an ESP provides consent for the EMS to share data generated by the ESP by selecting access controls presented within the GIU), the private records of the third computing device stored by the server (see mapping above, wherein paragraphs 69 and 81 reveal the EMS has clearing house storage/database for storing emergency data, location data, and additional data that is sent by communication devices (triggering devices ) and retrieved by various member devices/recipients). Paragraphs 9 and 295 disclose the user/triggering device is in a data sharing group. The data sharing comprising the one or more contacts linked to one or more member devices (including the trigger device). In some embodiments, the user has authorized location sharing with the one or more member devices associated with the one or more emergency contacts during the emergency. In some embodiments, the method further comprises obtaining a location of the user/(location of the triggering device, sensor device/third computing device) and sharing the location with one or more member devices authorized for location sharing according to the personalized notification procedure); and
display one or more of the records to which access was granted on a graphical user interface (GUI) of the sender computing device (paragraph 303 reveals displaying access controls to the asset within a GUI. Paragraph 70 discloses the trigger device has a notification module for displaying communications from the EFMS to the user (paragraph 20 discloses using the set of emergency data to determine a notification procedure/electronic communication to be executed/sent, and executing the notification procedure to one or more recipients. Paragraph 69 discloses the emergency data can be retrieved/transmitted and/or distributed to recipients (this may include triggering device/communication device, and/or emergency personnel device). See also paragraph 283).
Katz does not teach that the [software application] which is integrated into an application deployed on the server and used by the triggering/communication device is an artificial intelligence chat-bot.
Martin discloses that the [software application] which is integrated into an application deployed on the server and used by the triggering/communication device is an artificial intelligence chat-bot (paragraphs 82, 101, and 146 disclose an autonomous communication session via an artificial conversational entity(chatbot). The autonomous communication session may be held using different types of electronic devices and different interfaces of electronic devices).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Katz’s software application with the artificial conversational entity(chatbot) as taught by Martin such that the emergency management system can further gather emergency data or information regarding the emergency and deliver safety recommendations to one or more persons potentially affected by the emergency (paragraph 101 of Martin).
As to claim 12, the combination of Katz in view of Martin teaches wherein the determining of a mode of communication and the transmitting of the extracted data items are performed based on an exchange type, wherein the exchange type is generated using a GUI of an administrator device (Katz: paragraphs 102 and 113 reveal elements of the emergency flow are selected/configured or inputted by an administrator via the GUI. The execution of the emergency flow involves initiating communications with an output service such as EDC and PSAP. Accordingly, to paragraphs 116-118, the emergency flow is an exchange type (defined by emergency flow building blocks, which is defined by a script, see paragraph 106) that is configured to execute the communication type (interactive call to the trigger device , call to the customer service provider, bridge calls, or call PSAP) and transmit necessary components of the emergency alert (that includes the emergency data and additional data). Paragraph 125 further reveals the emergency flow scripts may be chosen based on additional user data. Paragraphs 126-140 further reveal a create emergency bridge block that is included in every emergency flow building block. The create emergency bridge block instructs the EFMS to create a communication bridge/communication type based on the emergency alert).
As to claim 13, the combination of Katz in view of Martin teaches comprising wherein one or more of the second information items are displayed on the graphical user interface (GUI) of the sender computing device (Katz: paragraph 303 reveals displaying access controls to the asset within a GUI. Paragraph 70 discloses the trigger device has a notification module for displaying communications from the EFMS to the user (paragraph 20 discloses using the set of emergency data to determine a notification procedure/electronic communication to be executed/sent, and executing the notification procedure to one or more recipients. Paragraph 69 discloses the emergency data can be retrieved/transmitted and/or distributed to recipients (this may include triggering device/communication device, and/or emergency personnel device). Paragraphs 69 and 81 reveal the EMS has clearing house storage/database for storing emergency data, location data, and additional data that is sent by communication devices (triggering devices ) and retrieved by various member devices/recipients). Paragraphs 9 and 295 disclose the user/triggering device is in a data sharing group. The data sharing comprising the one or more contacts linked to one or more member devices (including the trigger device). In some embodiments, the user has authorized location sharing with the one or more member devices associated with the one or more emergency contacts during the emergency. In some embodiments, the method further comprises obtaining a location of the user/(location of the triggering device, sensor device/third computing device) and sharing the location with one or more member devices authorized for location sharing according to the personalized notification procedure. In some embodiments, the location of the user is determined using location services for an electronic device associated with the user. In some embodiments, one or more emergency contacts of the user are authorized to receive additional data comprising images, video feed, sensor data, or ESP or response data during an emergency. In some embodiments, the one or more contacts comprise an emergency contact associated with the user identifier, or an organizational contact associated with the user identifier, or both).
As to claim 14, the combination of Katz in view of Martin teaches wherein the exchange type comprises one or more of: an array data structure, a dictionary, and a tree data structure (Katz: paragraphs 102 and 105-106 and 113 reveal elements of the emergency flow are selected/configured or inputted by an administrator via the GUI. Accordingly, to paragraphs 116-118, the emergency flow is an exchange type (defined by emergency flow building blocks, which is defined by a script, see paragraph 106. An array is a fundamental data structure that is used in scripting and programming to store ordered collections of elements. Furthermore, paragraph 142 discloses an emergency flow may be considered as a logic tree which can be a tree data structure) that is configured to execute the communication type (interactive call to the trigger device , call to the customer service provider, bridge calls, or call PSAP) and transmit necessary components of the emergency alert (that includes the emergency data and additional data)).
As to claim 15, the combination of Katz in view of Martin teaches wherein one or more of the destination computing devices device are associated with emergency contacts, and wherein one or more of the destination computing devices device are associated with medical care providers (Katz: paragraphs 58 and 273 disclose the EMS transmits the emergency alert data to an emergency service provider (which can be a first responder) based on the determined mode of communication, PSAP. (Recall, paragraph 92 above which discloses the emergency alert comprises list of contacts and emergency location to the EFMS. The EFMS executes the emergency flow comprising a mode of communication of a call contact to confirm the emergency, repeat with second contact if no response with first contact, and connecting to appropriate emergency service provider such as public safety answering point (PSAP) based on the provided location. Paragraphs 99 and 107 further disclose the EFMS receives the emergency alert and execute an emergency flow associated with the alert. The emergency flow involves determining a mode of communication based on the emergency flow ID, location data, and/or user data (contact information) sent by the triggering device, which involve mode of communication of contacting the triggering device for more information, another device for confirmation of the emergency, a nurse and/or calling 911 via SMS, MMS, text message, internet enabled communication service such as WhatsApp, Slack, Facebook Messenger via an API call or HTTP post, voice call(PSTN data or VoIP call), TTS message, or text to speech message communication).
As to claim 16, the combination of Katz in view of Martin teaches wherein one or more of the data items to be exchanged includes: a health record, and a blood type (Katz: paragraph 53 discloses the server of the emergency management system (EMS) receive/extract an emergency alert that is transmitted from triggering device. The emergency alert is the data item that comprises first information items of a list of at least one associated device of the triggering device. Paragraphs 274 and 303-304 also disclose an emergency alert that comprises location data. Paragraphs 4, 16, 19-20, and 97-98 further disclose the emergency alert also comprise an emergency flow identifier, user identifier, and additional data such as location data. Paragraphs 20 and 69 reveal emergency data includes user identifier, location data, medical data, personal information, and contact information).
As to claim 17, the combination of Katz in view of Martin teaches wherein the transmitting of the extracted data items is initiated by clicking a button on the GUI of the sender device (Katz: paragraph 82 discloses the emergency is triggered/transmitted by user input such as the user interacting with the user interface of the triggering device. In some embodiments, the user presses one or more hard or soft buttons on the user interface).
As to claim 18, the combination of Katz in view of Martin teaches wherein one or more of the destination computing devices are to automatically performed one or more computer operations based on one or more of the transmitted data items (Katz: paragraphs 58 and 275 disclose the destination computing devices ESP transmits a request for emergency data regarding the emergency, see also paragraph 305 wherein the ESP can activate a drone to receive a defibrillator. Paragraph 58 also reveals the request can be sent autonomously. Martin: paragraph 92 also discloses delivering a safety recommendations via the chat-box from the EMS once 911 call is made based on the emergency alert and data received by the sending computing device). Motivation is similar to the motivation presented in claim 10.
As to claim 19, Katz teaches a computerized method for performing data transfers over a computer network (abstract and paragraph 19 disclose systems, devices, methods, and media for connecting a user for providing emergency assistance based on emergency alerts from triggering devices that gather emergency information from one or more devices in computer network (mesh network, local network)) , the method comprising, by a server comprising a computer processor (paragraph 51 discloses an emergency management system that comprises a server. The server comprises a processor and memory):
retrieve, by the processor (paragraph 51 discloses an emergency management system that comprises servers 148/128/109. The server comprises a processor and memory), one or more data elements to be transferred based on one or more first data elements, wherein one or more of the first data elements are transmitted from an initiator computing device, thereby initiating an emergency communication protocol by the initiator computing device (paragraph 275 also discloses an embodiment where the ESP/initiator computing device receives an emergency call[ from a third computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. Paragraphs 273-274 disclose the EMS receives an emergency communication associated with the emergency from the ESP. The EMS can then process the emergency communication and any emergency data included therein and determine one or more recipients to notify of the emergency or share the emergency data with or determine one or more actions to take based on the emergency communication and emergency data. The EMS[server] extracts and can transmit the location data/one or more data items), the transmitting of one or more of the first information items triggered by [a software application] receiving input from the initiator computing device, wherein the [software application] is integrated into an application deployed on the server (paragraph 120 discloses emergency console allows a variety of customizable emergency flows between users, emergency contacts, emergency services, and related third parties by establishing a multitude of voice and data connections to Public Safety Answering Points (PSAPs) through a variety of trigger mechanisms the Emergency Console is operated on an emergency response server. In some embodiments, the EMS comprises an emergency response server. In some embodiments, the Emergency Console is a web interface that provides tools for generating and testing emergency flows. The Emergency Console allows for emergency flows to be initiated via simple API triggers from any device. Paragraph 275 reveals the ESP transmit the emergency communication to the EMS, when the ESP receives an emergency call, sending the emergency communication that comprises the first information in the form of a notification/input informing the EMS of the emergency call. The emergency notification may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. In some embodiments, the emergency communication is an API call received through an API (application programming interface) provided by the EMS . In some embodiments, the emergency communication is generated and transmitted to the EMS through an emergency response application executed on a computing device at the ESP. The EMS received the data from the ESP to execute emergency flows, notification procedure);
determining, by the processor (paragraph 51 discloses an emergency management system that comprises a server. The server comprises a processor and memory), a mode of transfer selected from a group consisting of short message service (SMS), telephone call and email (paragraphs 58 and 107 disclose the EFMS employs service actions to execute various emergency flows that requires transmitting data and communications to and from various users and output services using various mediums and communication modes such as SMS, MMS, voice call, text messages, see also Paragraphs 99 and 107), the determining based on: one or more of the first data elements transmitted from the initiator computing device, and a plurality of second data elements stored at the server, wherein one or more of the second data elements describe one or more target computing devices(paragraphs 86 and 107 disclose the emergency alert is sent via a cellular connection to the emergency flow management system which initiates an emergency flow script and an emergency call and a two way communication link may be established. Communication link is used for sending data such as user data, location data, emergency data, text, images, and video from the triggering device. Paragraph 92 further discloses the emergency alert comprises list of contacts and emergency location to the EFMS. The EFMS executes the emergency flow comprising a mode of communication of a call contact to confirm emergency, repeat with second contact if no response with first contact, and connecting to appropriate emergency service provider such as public safety answering point (PSAP) based on the provided location. Paragraphs 99 and 107 further disclose the EFMS receives the emergency alert and execute an emergency flow associated with the alert. The emergency flow involves determining a mode of communication based on the emergency flow ID, location data, and/or user data (contact information) sent by the ESP device, which involve mode of communication of contacting the triggering device for more information, another device for confirmation of the emergency, a nurse and/or calling 911 via SMS, MMS, text message, internet enabled communication service such as WhatsApp, Slack, Facebook Messenger via an API call or HTTP post, voice call(PSTN data or VoIP call), TTS message, or text to speech message communication. Therefore, the second information may involve contact information and location data), wherein one or more of the data items to be exchanged includes a username associated with one or more of the target computing devices (paragraph 53 discloses the server of the emergency management system (EMS) receive/extract an emergency alert that is transmitted from triggering device. The emergency alert is the data item that comprises first information items of a list of at least one associated device of the triggering device. Paragraphs 274 and 303-304 also disclose an emergency alert that comprises location data. Paragraphs 4, 16, 19-20, and 97-98 further disclose the emergency alert also comprise an emergency flow identifier, user identifier, and additional data such as location data. Paragraphs 20 and 69 reveal emergency data includes user identifier, location data, medical data, personal information, and contact information; paragraph 9 recites the user identifier is a username. A user name connected/linked to other devices via the emergency management system is associated with destination devices (emergency contacts, organizational contacts, institution, personal or professional service providers, etc., ). Paragraph 202 also recites the information regarding the selected emergency flow includes user names, contact names, and associated accounts (e.g., phone numbers, email accounts). Recall, per paragraph 99, the emergency flow is initiated/executed by EFMS. Once the EFMS receives an emergency alert (e.g., an API call generated by an emergency trigger script integrated into a computer program on a triggering device), the EFMS then executes an emergency flow associated with the emergency alert (e.g., an emergency flow associated with the emergency trigger script or any data included in the emergency alert)), wherein the retrieved data items elements and one or more of the second data elements were originally retrieved from an inaccessible computing device (paragraphs 14, 81, and 331-332 disclose the account is registered by the user device/ in accessible computing device to include a list of contact information for the user such as, for example, a list of associated devices. Examples of contact information on an account include phone number, email address, home address, work address, emergency contacts (e.g., name, phone number, email, etc.), and associated devices/target devices (e.g., other communication devices of the user aside from the device or triggering device sending an emergency alert), the inaccessible computing device separate from the initiator computing device and from the server (paragraphs 273-274 and 331-332 reveal the inaccessible computing device is a mobile device or device of the user and is separate from the EMS server/processor and the ESP devices/initiator computing devices), wherein an emergency is occurring for the inaccessible computing device at a time of the transmitting of one or more of the first data elements from the initiator computing device (paragraph 275 also discloses an embodiment where the ESP/initiator computing device receives an emergency call[ from an inaccessible computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day), wherein the inaccessible computing device is unable to initiate the emergency communication protocol (paragraph 355 reveals the smart watch is the triggering device initialing an alert by an elderly patient, John, has fallen. The smartphone/third computing device is out of the elderly patient reach. Therefore, the third computing device is unable to initiate the emergency communication protocol because the phone is not in the patient reached to initiate the emergency), wherein the retrieved data elements describe the emergency (paragraph 275 also discloses an embodiment where the ESP/initiator computing device receives an emergency call[ from an inaccessible computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day), and wherein the retrieved data elements are received from the inaccessible computing device upon registering to the application deployed on the server (paragraphs 14, 81, and 331-332 disclose the account is registered on the EMS by the user using the mobile application or web application to include a list of contact information for the user such as, for example, a list of associated devices. Examples of contact information on an account include phone number, email address, home address, work address, emergency contacts (e.g., name, phone number, email, etc.), and associated devices/target computing devices (e.g., other communication devices of the user aside from the device or triggering device sending an emergency alert), and wherein the one or more first data elements transmitted from the initiator computing device comprise an identifier of the inaccessible computing device (paragraph 275 also discloses an embodiment where the ESP/sender computing device receives an emergency call[ from an inaccessible computing device/mobile device/trigger device], the ESP transmits an emergency communication to the EMS in the form of a notification, informing the EMS of the emergency call. The emergency notification (first information) may include an identifier (e.g., the phone number of the emergency caller);
transferring, by the processor (paragraph 51 discloses an emergency management system that comprises a server. The server comprises a processor and memory), the retrieved data elements to one or more of the target computing devices based on the determined mode of transfer, the data elements comprising an alert message; granting the initiator computing device access to one or more records describing the inaccessible computing device, the one or more records stored at the server (Paragraphs 273-274 and 287 disclose after the EMS receives an emergency communication associated with the emergency from the ESP, the EMS process the emergency communication and any emergency data included therein and determine one or more recipients (target computing devices) to notify of the emergency or share the emergency data with or determine one or more actions to take based on the emergency communication and emergency data. The target computing devices include emergency contacts, organizational contacts, institutions, personal and professional service providers (PSPs), and other ESPs. Paragraph 120 discloses emergency console allows a variety of customizable emergency flows between users, emergency contacts, emergency services, and related third parties by establishing a multitude of voice and data connections to Public Safety Answering Points (PSAPs) through a variety of trigger mechanisms the Emergency Console is operated on an emergency response server. In some embodiments, the EMS comprises an emergency response server. Paragraph 275 reveals the ESP transmit the emergency communication to the EMS, when the ESP receives an emergency call, sending the emergency communication that comprises the first information in the form of a notification/input informing the EMS of the emergency call. The emergency notification may include an identifier (e.g., the phone number of the emergency caller) and any other data relevant to the call or the caller's emergency that the ESP may have access to or gathered, such as the day and time of the emergency call, the nature of the emergency, or the caller's location. In some embodiments, the emergency communication is an API call received through an API (application programming interface) provided by the EMS . In some embodiments, the emergency communication is generated and transmitted to the EMS through an emergency response application executed on a computing device at the ESP. The EMS received the data from the ESP to execute emergency flows, notification procedure), wherein the
granting of the access is based on a location of the inaccessible computing device, wherein the granting of the access to the one or more records describing the inaccessible computing device is performed while private records of the inaccessible computing device are inaccessible to the initiator computing device, the private records of the inaccessible computing device stored by the server (paragraph 69 discloses the EMS server grants access to records of the inaccessible computing device/user mobile device to the initiator computing devices (sender devices listed above). The records are stored in the EMS databases. The EMS grants access to the target devices of data records that are pertinent for the emergency and requested by the ESP. Therefore, data records that are not pertinent will not be delivered/transmitted). Paragraph 81 also reveals setting up registration for the devices (triggering device data and third computing/communication device data) that include emergency contact data, location data, user data. The data is saved in the database of the EMS or third party servers and the data is protected by password, authentication protocols for transmissions. Therefore, certain data of the inaccessible computing device will not be accessible as a result of password protection, authentication protocols for transmissions. Paragraph 304 also reveals an ESP provides consent for the EMS to share data generated by the ESP by selecting access controls presented within the GIU), the private records of the inaccessible computing device stored by the server (see mapping above, wherein paragraphs 69 and 81 reveal the EMS has clearing house storage/database for storing emergency data, location data, and additional data that is sent by communication devices (triggering devices ) and retrieved by various member devices/recipients). Paragraphs 9 and 295 disclose the user/inaccessible device is in a data sharing group. The data sharing comprising the one or more contacts linked to one or more member devices. In some embodiments, the user has authorized location sharing with the one or more member devices associated with the one or more emergency contacts during the emergency. In some embodiments, the method further comprises obtaining a location of the user/(location of the inaccessible computing device) and sharing the location with one or more member devices authorized for location sharing according to the personalized notification procedure. Paragraphs 295-296 also disclose EMS implementing geofence system to sharing the data to the target device and initiator device based on the location of the inaccessible device and the location of the target devices and/or initiator devices such as ESP); and
displaying one or more of the records to which access was granted on a graphical interface of the initiator computing device (paragraph 303 reveals displaying access controls to the asset within a GUI. Paragraph 70 discloses displaying communications from the EFMS to the user (paragraph 20 discloses using the set of emergency data to determine a notification procedure/electronic communication to be executed/sent, and executing the notification procedure to one or more recipients. Paragraph 69 discloses the emergency data can be retrieved/transmitted and/or distributed to recipients (this may include initiator computing device such as emergency personnel device). See also paragraph 283).
Katz does not teach that the [software application] which is integrated into an application deployed on the server and used by the triggering/communication device is an artificial intelligence chat-bot.
Martin discloses that the [software application] which is integrated into an application deployed on the server and used by the triggering/communication device is an artificial intelligence chat-bot (paragraphs 82, 101, and 146 disclose an autonomous communication session via an artificial conversational entity(chatbot). The autonomous communication session may be held using different types of electronic devices and different interfaces of electronic devices).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Katz’s software application with the artificial conversational entity(chatbot) as taught by Martin such that the emergency management system can further gather emergency data or information regarding the emergency and deliver safety recommendations to one or more persons potentially affected by the emergency (paragraph 101 of Martin).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexander Lagor can be reached at (571)270-5143. 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.
/F.F/Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437