DETAILED ACTION
1. 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
2. Receipt of Applicant’s Amendment filed on 06/24/2026 is acknowledged. The amendment includes the amending of claims 1-2, 10-12, and 18-19 and the amending of the specification.
Terminal Disclaimer
3. The terminal disclaimer filed on 06/24/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of U.S. Patent 12,417,232, U.S. Patent Application 19/075883, and U.S. Patent Application 19/075929 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Specification
4. The objection raised in the Office Action mailed on 04/06/2026 has been overcome by applicant’s amendment received on 06/24/2026.
Claim Objections
5. The objections raised in the Office Action mailed on 04/06/2026 have been overcome by applicant’s amendment received on 06/24/2026.
Claim Rejections - 35 USC § 112
6. The rejections raised in the Office Action mailed on 04/06/2026 have been overcome by applicant’s amendment received on 06/24/2026.
Claim Rejections - 35 USC § 101
7. The rejections raised in the Office Action mailed on 04/06/2026 have been overcome by applicant’s amendment received on 06/24/2026.
Double Patenting
8. The rejections raised in the Office Action mailed on 04/06/2026 have been overcome by applicant’s submission of a Terminal Disclaimer received on 06/24/2026.
Claim Rejections - 35 USC § 103
9. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
10. 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.
11. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
12. Claims 1, 5-6, 9-11, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Salazar et al. (U.S. PGPUB 2018/0218126), in view of Pal et al. (U.S. PGPUB 2017/0053461), and further in view of Chen et al. (CN104933839A (Machine Translation Provided)).
13. Regarding claims 1, 11, and 19, Salazar teaches a computer-method, computer system, and tangible, non-transitory computer-readable medium comprising:
A) acquiring at least two data streams of a patient by using one or more sensors (Paragraph 19);
C) generating at least one entity-feature-graph based on the acquired at least two data streams of the patient (Paragraphs 19, 27, 43, and 45);
D) selecting at least one intervention based on the generated entity-feature-graph, a trained graph classification model (Paragraphs 19, 40, and 45); and
E) outputting an information of the selected intervention to a user (Paragraphs 19 and 45).
The examiner notes that Salazar teaches “acquiring at least two data streams of a patient by using one or more sensors” as “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19). The examiner further notes that multiple “streams” of patient data (including transcripts (i.e. text), audio, video, images, etc)) are acquired via the use of one or more “sensors” (such as a camera and/or microphone for a video call for example). The examiner further notes that Salazar teaches “generating at least one entity-feature-graph based on the acquired at least two data streams of the patient” as “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19), “The training set database 245 stores one or more patient complaint-symptom datasets that are used to generate the knowledge graph 225. These datasets are further described in conjunction with FIG. 6. In some embodiments, the training set database 245 is combined with the patient information database 205” (Paragraph 27), “If the medical triage assistance system 200 receives a correction to the symptoms from the nurse, it can use that feedback to rebalance the connections of the knowledge graph 225 and re-score the multi-class classifier. A nurse can provide a correction by selecting the correct symptom that should have been identified, such as through a multiple-choice interface. The knowledge graph 225 is recomputed based on the correction and the recomputed knowledge graph 225 replaces the current knowledge graph 225 once a threshold improvement in performance is reached. Previous versions of the knowledge graph 225 may be stored to allow for analysis of historical data and models” (Paragraph 43), and “The medical triage assistance system 200 may also select 340 one or more specific medical protocols to recommend based on the patient's symptoms. Each medical protocol is based on one or more symptoms and is made up of a series of questions that are designed to differentiate between life-threatening conditions associated with that symptom and less urgent conditions. The medical triage assistance system 200 maps specific medical protocols to the various medical concepts of the knowledge graph 225. This mapping can be manually created, or learned (i.e., as part of the knowledge graph 225) based on existing patient cases. The medical triage assistance system 200 selects 340 the medical protocols based on confidence scoring. The medical triage assistance system 200 may present the selected 340 protocol(s) to the nurse as a recommendation and wait for approval or correction before proceeding” (Paragraph 45). The examiner further notes that an output recommendation (i.e. intervention) is based on a generated knowledge graph (i.e. the claimed undefined entity-feature graph in the broadest reasonable interpretation) that is generated “based” on received multiple streams of patient data. The examiner further notes that Salazar teaches “selecting at least one intervention based on the generated entity-feature-graph, a trained graph classification model” as “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19), “The knowledge graph 225 may also be traversed based on probabilistic modeling and detection of anchors and triplets, or deep Kalman filters, including deep learning and probabilistic modeling” (Paragraph 40), “If the medical triage assistance system 200 receives a correction to the symptoms from the nurse, it can use that feedback to rebalance the connections of the knowledge graph 225 and re-score the multi-class classifier. A nurse can provide a correction by selecting the correct symptom that should have been identified, such as through a multiple-choice interface. The knowledge graph 225 is recomputed based on the correction and the recomputed knowledge graph 225 replaces the current knowledge graph 225 once a threshold improvement in performance is reached. Previous versions of the knowledge graph 225 may be stored to allow for analysis of historical data and models” (Paragraph 43), and “The medical triage assistance system 200 may also select 340 one or more specific medical protocols to recommend based on the patient's symptoms. Each medical protocol is based on one or more symptoms and is made up of a series of questions that are designed to differentiate between life-threatening conditions associated with that symptom and less urgent conditions. The medical triage assistance system 200 maps specific medical protocols to the various medical concepts of the knowledge graph 225. This mapping can be manually created, or learned (i.e., as part of the knowledge graph 225) based on existing patient cases. The medical triage assistance system 200 selects 340 the medical protocols based on confidence scoring. The medical triage assistance system 200 may present the selected 340 protocol(s) to the nurse as a recommendation and wait for approval or correction before proceeding” (Paragraph 45). The examiner further notes that a selected intervention is based off of a generated knowledge graph (i.e. the claimed undefined entity feature graph in the broadest reasonable interpretation) that is traversed/mapped via a learned process (i.e. the use of a “trained graph classification model” (which is undefined in the claims) in the broadest reasonable interpretation). The examiner further notes that Salazar teaches “outputting an information of the selected intervention to a user” as “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19) and “The medical triage assistance system 200 may also select 340 one or more specific medical protocols to recommend based on the patient's symptoms. Each medical protocol is based on one or more symptoms and is made up of a series of questions that are designed to differentiate between life-threatening conditions associated with that symptom and less urgent conditions. The medical triage assistance system 200 maps specific medical protocols to the various medical concepts of the knowledge graph 225. This mapping can be manually created, or learned (i.e., as part of the knowledge graph 225) based on existing patient cases. The medical triage assistance system 200 selects 340 the medical protocols based on confidence scoring. The medical triage assistance system 200 may present the selected 340 protocol(s) to the nurse as a recommendation and wait for approval or correction before proceeding” (Paragraph 45). The examiner further notes that a selected intervention is output.
Salazar does not explicitly teach:
B) determining a location of an event based on the acquired at least two data streams of the patient;
D) selecting at least one intervention based on information related to the determined location of the event.
Pal, however, teaches “determining a location of an event based on the acquired at least two data streams of the patient” as “movement data preferably refers to any data related to the position, velocity, and/or acceleration of one or more vehicles for which vehicular accident events are to be detected through the method 100. In examples, movement data can include only acceleration data (and not position/velocity data). Movement data can include any one or more of: a location dataset, a motion dataset, and/or any other suitable data related to the position and/or movement of one or more vehicles. Movement data can be collected from and/or associated with any one or more of: motion sensors (e.g., multi-axis and/or single-axis accelerometers, gyroscopes, etc.), location sensors (e.g., GPS data collection components, magnetometer, compass, altimeter, etc.), and/or any other suitable components. Such components are preferably arranged at a mobile computing device (e.g., smartphone, laptop, tablet, smart watch, smart glasses, medical devices, etc.) associated with a user (e.g., a vehicle driver)” (Paragraph 31), “Block S120 can optionally include Block S121, which recites: collecting audio data. Block S121 preferably includes collecting audio data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing recorded audio for sounds related to or resulting from impacts). For example, audio data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording engine noise), the nature, location, and/or severity of an accident (e.g., by recording impact noise), and the effect of the accident on the vehicle's occupants (e.g., by recording voice data for a vehicle's occupants)” (Paragraph 55), and “Block S120 can optionally include Block S122, which recites: collecting video data. Block S122 preferably includes collecting video data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing video to determine how far the mobile computing device was moved during an accident). For example, video data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording visuals of the vehicle's exterior), the nature, location, and/or severity of an accident (e.g., by recording visuals of an impact site), and the effect of the accident on the vehicle's occupants (e.g., by recording video data of a vehicle's occupants)” (Paragraph 59) and “selecting at least one intervention based on information related to the determined location of the event” as “movement data preferably refers to any data related to the position, velocity, and/or acceleration of one or more vehicles for which vehicular accident events are to be detected through the method 100. In examples, movement data can include only acceleration data (and not position/velocity data). Movement data can include any one or more of: a location dataset, a motion dataset, and/or any other suitable data related to the position and/or movement of one or more vehicles. Movement data can be collected from and/or associated with any one or more of: motion sensors (e.g., multi-axis and/or single-axis accelerometers, gyroscopes, etc.), location sensors (e.g., GPS data collection components, magnetometer, compass, altimeter, etc.), and/or any other suitable components. Such components are preferably arranged at a mobile computing device (e.g., smartphone, laptop, tablet, smart watch, smart glasses, medical devices, etc.) associated with a user (e.g., a vehicle driver)” (Paragraph 31), “Block S120 can optionally include Block S121, which recites: collecting audio data. Block S121 preferably includes collecting audio data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing recorded audio for sounds related to or resulting from impacts). For example, audio data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording engine noise), the nature, location, and/or severity of an accident (e.g., by recording impact noise), and the effect of the accident on the vehicle's occupants (e.g., by recording voice data for a vehicle's occupants)” (Paragraph 55), “Block S120 can optionally include Block S122, which recites: collecting video data. Block S122 preferably includes collecting video data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing video to determine how far the mobile computing device was moved during an accident). For example, video data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording visuals of the vehicle's exterior), the nature, location, and/or severity of an accident (e.g., by recording visuals of an impact site), and the effect of the accident on the vehicle's occupants (e.g., by recording video data of a vehicle's occupants)” (Paragraph 59), and “accident response actions can include any one or more of: presenting an accident-related notification (e.g., in Block S151), contacting emergency services (e.g., in Block S152), facilitating insurance processing (e.g., in Block S153), facilitating communication with a virtual assistant (e.g., in Block S154), communicating with a mobile computing device (e.g., in Block S155), storing accident-related data (e.g. storing movement data and/or supplemental data at a mobile computing device, at a remote server, etc.) and/or an other suitable types of response actions” (Paragraph 115), and “communications transmitted to emergency services preferably include accident-related information (e.g., movement data, supplemental data, accident characteristics, etc.). In an example, the method 100 can include receiving a camera dataset captured at a camera mounted to the vehicle; determining a number of passengers in the vehicle from the camera dataset, where the audio sample includes the number of passengers in the vehicle (e.g., in addition to GPS coordinates associated with the vehicular accident event and/or other suitable information)” (Paragraph 126).
The examiner further notes that the secondary reference of Pal teaches the concept of ascertaining location information from multiple streams of accident victim(s) (i.e. patient(s) in the broadest reasonable interpretation). Such ascertained location information is used to dispatch emergency services (i.e. an intervention selection). The combination would result in using location information to expand the intervention selection of Salazar.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Pal’s would have allowed Salazar’s to provide a method for improving the response delivery to accident detection, as noted by Pal (Paragraph 4).
Salazar and Pal do not explicitly teach:
F) adapting a position, location, and/or an orientation of the one or more sensors based on the selected intervention.
Chen, however, teaches “adapting a position, location, and/or an orientation of the one or more sensors based on the selected intervention” as “Step 106: After the caller clicks "Yes" to receive the real-time video request, the receiving police officer sees the scene captured by the built-in camera of the smart phone terminal and transmitted in real time through the data transmission network in the image/video display area of the police software interface video. In addition, the receiving police officer can remotely command the alarm person to adjust the shooting angle and distance and take effective measures to deal with the accident through telephone voice communication. At this time, the smartphone terminal is equivalent to a remote pan-tilt for the receiving police officer to use” (Page 07).
The examiner further notes that the secondary reference of Chen teaches the concept of adjusting a shooting angle and distance (i.e. examples of the claimed adapting of a position, location, and/or orientation) of a camera (i.e. sensor). Such an adjustment is “based” off of instructions from emergency personnel (i.e. an example of the claimed selected intervention in the broadest reasonable interpretation) to an accident. The combination would result in the emergency personnel (i.e. an example of the claimed selected intervention in the broadest reasonable interpretation) of Pal and the selected intervention of Salazar to be able to adjust the location, position, and/or orientation of its sensors.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Chen’s would have allowed Salazar’s and Pal’s to provide a method for authorities to be able to remotely pan/tilt sensors, as noted by Chen (Page 07).
Regarding claims 5 and 15, Salazar further teaches a computer-implemented method and computer system comprising:
A) wherein the at least two data streams include at least one data stream including images and at least one data stream including text (Paragraph 19); and
B) wherein the one or more sensors include at least one of a camera, sound recorder, presence sensor, a temperature sensor, a sound-level sensor, and a door sensor (Paragraph 19).
The examiner notes that Salazar teaches “wherein the at least two data streams include at least one data stream including images and at least one data stream including text” as “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19). The examiner further notes that multiple “streams” of patient data (including images and transcripts (i.e. text)) are acquired via the use of one or more “sensors” (such as a camera for a video call for example). The examiner further notes that Salazar teaches “wherein the one or more sensors include at least one of a camera, sound recorder, presence sensor, a temperature sensor, a sound-level sensor, and a door sensor” as “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19). The examiner further notes that multiple “streams” of patient data (including images and transcripts (i.e. text)) are acquired via the use of one or more “sensors” (such as a camera for a video call for example).
Regarding claims 6 and 16, Salazar does not explicitly teach a computer-implemented method and computer system comprising:
A) determining based on the at least two data streams that the patient has suffered an accident; and
B) executing the selected intervention of establishing a phone connection with an emergency contact associated with the patient.
Pal, however, teaches “determining based on the at least two data streams that the patient has suffered an accident” as “movement data preferably refers to any data related to the position, velocity, and/or acceleration of one or more vehicles for which vehicular accident events are to be detected through the method 100. In examples, movement data can include only acceleration data (and not position/velocity data). Movement data can include any one or more of: a location dataset, a motion dataset, and/or any other suitable data related to the position and/or movement of one or more vehicles. Movement data can be collected from and/or associated with any one or more of: motion sensors (e.g., multi-axis and/or single-axis accelerometers, gyroscopes, etc.), location sensors (e.g., GPS data collection components, magnetometer, compass, altimeter, etc.), and/or any other suitable components. Such components are preferably arranged at a mobile computing device (e.g., smartphone, laptop, tablet, smart watch, smart glasses, medical devices, etc.) associated with a user (e.g., a vehicle driver)” (Paragraph 31), “Block S120 can optionally include Block S121, which recites: collecting audio data. Block S121 preferably includes collecting audio data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing recorded audio for sounds related to or resulting from impacts). For example, audio data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording engine noise), the nature, location, and/or severity of an accident (e.g., by recording impact noise), and the effect of the accident on the vehicle's occupants (e.g., by recording voice data for a vehicle's occupants)” (Paragraph 55), “Block S120 can optionally include Block S122, which recites: collecting video data. Block S122 preferably includes collecting video data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing video to determine how far the mobile computing device was moved during an accident). For example, video data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording visuals of the vehicle's exterior), the nature, location, and/or severity of an accident (e.g., by recording visuals of an impact site), and the effect of the accident on the vehicle's occupants (e.g., by recording video data of a vehicle's occupants)” (Paragraph 59), and “Block S140 preferably includes detecting a vehicular accident event based on the set of movement features. For example, Block S140 can include detecting a vehicular accident event from processing the set of movement features with an accident detection model. In another example, Block S140 can include detecting a vehicular accident event with the accident detection model and at least one of a location dataset and a motion dataset (e.g., a location dataset and motion dataset received in response to satisfaction of a comparison to a threshold in Block S142). In another example, Block S142 can include detecting a vehicular accident event from processing a vertical vehicular motion feature with the accident detection model. Additionally or alternately, Block S142 can include detecting a vehicular accident event based on supplemental data” (Paragraphs 92-93), and “executing the selected intervention of establishing a phone connection with an emergency contact associated with the patient” as “movement data preferably refers to any data related to the position, velocity, and/or acceleration of one or more vehicles for which vehicular accident events are to be detected through the method 100. In examples, movement data can include only acceleration data (and not position/velocity data). Movement data can include any one or more of: a location dataset, a motion dataset, and/or any other suitable data related to the position and/or movement of one or more vehicles. Movement data can be collected from and/or associated with any one or more of: motion sensors (e.g., multi-axis and/or single-axis accelerometers, gyroscopes, etc.), location sensors (e.g., GPS data collection components, magnetometer, compass, altimeter, etc.), and/or any other suitable components. Such components are preferably arranged at a mobile computing device (e.g., smartphone, laptop, tablet, smart watch, smart glasses, medical devices, etc.) associated with a user (e.g., a vehicle driver)” (Paragraph 31), “Block S120 can optionally include Block S121, which recites: collecting audio data. Block S121 preferably includes collecting audio data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing recorded audio for sounds related to or resulting from impacts). For example, audio data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording engine noise), the nature, location, and/or severity of an accident (e.g., by recording impact noise), and the effect of the accident on the vehicle's occupants (e.g., by recording voice data for a vehicle's occupants)” (Paragraph 55), “Block S120 can optionally include Block S122, which recites: collecting video data. Block S122 preferably includes collecting video data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing video to determine how far the mobile computing device was moved during an accident). For example, video data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording visuals of the vehicle's exterior), the nature, location, and/or severity of an accident (e.g., by recording visuals of an impact site), and the effect of the accident on the vehicle's occupants (e.g., by recording video data of a vehicle's occupants)” (Paragraph 59), and “Accident-related notifications can be presented to: authorities (e.g., a local police station), a service (e.g., emergency services, ride-sharing services, valet services, mapping services, navigation services, etc.), user-selected contacts, friends, family, loved ones, and/or any suitable entity. Accident-related notifications can include content in the form of one or more of: audio, graphical, verbal, and/or other suitable form. Further, accident-related notifications can be in the form of any one or more of: a phone call, a text message, an e-mail message, a printed message, a human notifier, and/or any other suitable form” (Paragraph 119).
The examiner further notes that the secondary reference of Pal teaches the concept of phoning selected contact(s) of an accident victim (i.e. patient in the broadest reasonable interpretation) in response to detecting an accident from multiple streams. The combination would result in detecting accidents and subsequently phoning contacts in the system of Salazar.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Pal’s would have allowed Salazar’s to provide a method for improving the response delivery to accident detection, as noted by Pal (Paragraph 4).
Regarding claims 9 and 17, Salazar does not explicitly teach a computer-implemented method and computer system comprising:
A) wherein determining the location of the event comprises: processing data in the at least two data streams for a location information, and/or processing video data contained in the at least two data streams, which is the basis for decision making, and scanning images from the video data for the location information.
Pal, however, teaches “wherein determining the location of the event comprises: processing data in the at least two data streams for a location information, and/or processing video data contained in the at least two data streams, which is the basis for decision making, and scanning images from the video data for the location information” as “movement data preferably refers to any data related to the position, velocity, and/or acceleration of one or more vehicles for which vehicular accident events are to be detected through the method 100. In examples, movement data can include only acceleration data (and not position/velocity data). Movement data can include any one or more of: a location dataset, a motion dataset, and/or any other suitable data related to the position and/or movement of one or more vehicles. Movement data can be collected from and/or associated with any one or more of: motion sensors (e.g., multi-axis and/or single-axis accelerometers, gyroscopes, etc.), location sensors (e.g., GPS data collection components, magnetometer, compass, altimeter, etc.), and/or any other suitable components. Such components are preferably arranged at a mobile computing device (e.g., smartphone, laptop, tablet, smart watch, smart glasses, medical devices, etc.) associated with a user (e.g., a vehicle driver)” (Paragraph 31), “Block S120 can optionally include Block S121, which recites: collecting audio data. Block S121 preferably includes collecting audio data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing recorded audio for sounds related to or resulting from impacts). For example, audio data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording engine noise), the nature, location, and/or severity of an accident (e.g., by recording impact noise), and the effect of the accident on the vehicle's occupants (e.g., by recording voice data for a vehicle's occupants)” (Paragraph 55), and “Block S120 can optionally include Block S122, which recites: collecting video data. Block S122 preferably includes collecting video data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing video to determine how far the mobile computing device was moved during an accident). For example, video data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording visuals of the vehicle's exterior), the nature, location, and/or severity of an accident (e.g., by recording visuals of an impact site), and the effect of the accident on the vehicle's occupants (e.g., by recording video data of a vehicle's occupants)” (Paragraph 59).
The examiner further notes that the secondary reference of Pal teaches the concept of ascertaining location information from multiple streams of accident victim(s) (i.e. patient(s) in the broadest reasonable interpretation). Such ascertained location from multiple streams entails that such streams are “processed” to obtain the location information in the first place. The combination would result in using location information to expand the intervention selection of Salazar.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Pal’s would have allowed Salazar’s to provide a method for improving the response delivery to accident detection, as noted by Pal (Paragraph 4).
Regarding claims 10 and 18, Salazar does not explicitly teach a computer-implemented method and computer-implemented method comprising:
A) identifying, based on the at least one selected intervention, further sensors and/or adapting characteristics of already identified sensors including positions of the sensors, orientation of the sensors, and/or sensitivity of the sensors.
Pal, however, teaches “identifying, based on the at least one selected intervention, further sensors and/or adapting characteristics of already identified sensors including positions of the sensors, orientation of the sensors, and/or sensitivity of the sensors” as “movement data preferably refers to any data related to the position, velocity, and/or acceleration of one or more vehicles for which vehicular accident events are to be detected through the method 100. In examples, movement data can include only acceleration data (and not position/velocity data). Movement data can include any one or more of: a location dataset, a motion dataset, and/or any other suitable data related to the position and/or movement of one or more vehicles. Movement data can be collected from and/or associated with any one or more of: motion sensors (e.g., multi-axis and/or single-axis accelerometers, gyroscopes, etc.), location sensors (e.g., GPS data collection components, magnetometer, compass, altimeter, etc.), and/or any other suitable components. Such components are preferably arranged at a mobile computing device (e.g., smartphone, laptop, tablet, smart watch, smart glasses, medical devices, etc.) associated with a user (e.g., a vehicle driver)” (Paragraph 31), “Block S120 can optionally include Block S121, which recites: collecting audio data. Block S121 preferably includes collecting audio data that can be used to detect that an accident has occurred and/or the severity of an accident (e.g., by analyzing recorded audio for sounds related to or resulting from impacts). For example, audio data can provide information on the status of a vehicle before/during/after an accident (e.g., by recording engine noise), the nature, location, and/or severity of an accident (e.g., by recording impact noise), and the effect of the accident on the vehicle's occupants (e.g., by recording voice data for a vehicle's occupants)” (Paragraph 55), and “Block S153 can include automatically initiating a first notice of loss (FNOL) for alerting insurance companies associated with participants in the vehicular accident event. In another example, Block S153 can include receiving, at a mobile computing device, a selection from a user permitting information release to an insurance company, where the user is driving the vehicle during the time period, and where automatically initiating the accident response action includes automatically transmitting, to the insurance company, accident-related information derived from the movement dataset and associated with the vehicular accident event. In another example, Block S153 can include guiding a vehicular accident event participant through actions to take for properly filing an insurance claim (e.g., information to obtain, documents to file, questions to ask different parties, etc.). In another example, Block S153 can include deriving accident-related information from one or more camera datasets (e.g., captured by a mobile computing device, captured by a vehicular camera, etc.), and automatically preparing an insurance claim with the accident-related information. In another example, insurance-related information can be derived from social network data associated with one or more participants in the vehicular accident event” (Paragraph 129).
The examiner further notes that the secondary reference of Pal teaches the concept of “identifying” a camera sensor in response to an identified “intervention” of an insurance claim. The combination would result in identifying a sensor in response to the intervention selection of Salazar.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Pal’s would have allowed Salazar’s to provide a method for improving the response delivery to accident detection, as noted by Pal (Paragraph 4).
14. Claims 2, 12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Salazar et al. (U.S. PGPUB 2018/0218126), in view of Pal et al. (U.S. PGPUB 2017/0053461), and further in view of Chen et al. (CN104933839A (Machine Translation Provided)) as applied to claims 1, 5-6, 9-11, and 15-19 above, and in view of Badr et al. (U.S. PGPUB 2018/0324117).
15. Regarding claims 2 and 12, Salazar further teaches a computer-method and computer system comprising:
A) wherein the trained graph classification model is trained by a learning process that considers confidence values assigned to each entity of a set of entities within the entity-feature-graph (Paragraphs 27, 40, 43, and 45).
The examiner notes that Salazar teaches “wherein the trained graph classification model is trained by a learning process that considers confidence values assigned to each entity of a set of entities within the entity-feature-graph” as “The training set database 245 stores one or more patient complaint-symptom datasets that are used to generate the knowledge graph 225. These datasets are further described in conjunction with FIG. 6. In some embodiments, the training set database 245 is combined with the patient information database 205” (Paragraph 27), “the medical triage assistance system 200 determines 330 the patient's symptoms based on the relevant conversation tokens. The medical triage assistance system 200 traverses the knowledge graph 225 based on the relevant conversation tokens and determines a probability and confidence level that the tokens are associated with specific symptoms. One method for generating the knowledge graph 225 is described in conjunction with FIGS. 7-8. Various complex network metrics, such as adjacency matrices and geodesic paths, may be used to traverse the knowledge graph 225. The knowledge graph 225 may also be traversed based on probabilistic modeling and detection of anchors and triplets, or deep Kalman filters, including deep learning and probabilistic modeling. Multiple symptoms can be presented to the nurse, along with the calculated probabilities and confidence levels” (Paragraph 40), “If the medical triage assistance system 200 receives a correction to the symptoms from the nurse, it can use that feedback to rebalance the connections of the knowledge graph 225 and re-score the multi-class classifier. A nurse can provide a correction by selecting the correct symptom that should have been identified, such as through a multiple-choice interface. The knowledge graph 225 is recomputed based on the correction and the recomputed knowledge graph 225 replaces the current knowledge graph 225 once a threshold improvement in performance is reached. Previous versions of the knowledge graph 225 may be stored to allow for analysis of historical data and models” (Paragraph 43), and “The medical triage assistance system 200 may also select 340 one or more specific medical protocols to recommend based on the patient's symptoms. Each medical protocol is based on one or more symptoms and is made up of a series of questions that are designed to differentiate between life-threatening conditions associated with that symptom and less urgent conditions. The medical triage assistance system 200 maps specific medical protocols to the various medical concepts of the knowledge graph 225. This mapping can be manually created, or learned (i.e., as part of the knowledge graph 225) based on existing patient cases. The medical triage assistance system 200 selects 340 the medical protocols based on confidence scoring. The medical triage assistance system 200 may present the selected 340 protocol(s) to the nurse as a recommendation and wait for approval or correction before proceeding” (Paragraph 45). The examiner further notes that a selected intervention is based off of a generated knowledge graph (i.e. the claimed undefined entity feature graph in the broadest reasonable interpretation) that is traversed/mapped via a learned process (i.e. the use of a “trained graph classification model” (which is undefined in the claims) in the broadest reasonable interpretation). Such a learned process is learned based on probabilities/confidence values of the knowledge graph.
Salazar, Pal, and Chen do not explicitly teach:
B) the confidence values indicating confidence levels with which respective ones of the entities are extracted from the at least two data streams.
Badr, however, teaches “the confidence values indicating confidence levels with which respective ones of the entities are extracted from the at least two data streams” as “if a digital image received by module 108 includes a particular content item(s) such as the Eiffel tower, and/or a dog standing in front of the Eiffel tower, then module 108 can use logic 204 to extract image features, or pixel data, that correspond to at least one of: a) the Eiffel tower, or b) the dog. Module 108 can then use label generation logic 206 to generate one or more labels (e.g., words, or text phrases) based on extracted features for Eiffel tower and dog” (Paragraph 43) and “labels that are more definitive or descriptive of particular attributes or extracted image features of an item of digital content may be assigned a higher confidence score relative to labels that more generic. For example, referencing the above extracted features for the Eiffel tower and the dog, descriptive labels such as “Eiffel” or “Eiffel tower” may receive higher confidence scores when compared to more generic labels such as “tower” or “Paris.” Likewise, descriptive labels such as “golden retriever” or “cute cocker spaniel” may receive higher confidence scores when compared to more generic labels such as “dog” or “cute dog.” (Paragraph 46)”.
The examiner further notes that although Salazar teaches probabilities/confidence values, there is no explicit teaching that such values are indicative of levels of extracted entities. Nevertheless, Badr teaches the concept of confidence values that are indicative of extracted entities from images. The combination would result in expanding Salazar to also have confidence values that are indicative of levels of extracted entities.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Badr’s would have allowed Salazar’s, Pal’s, and Chen’s to provide a method for indicating a relevance level of extracted features, as noted by Badr (Paragraph 45).
Regarding claim 20, Salazar further teaches a tangible, non-transitory computer-readable medium comprising:
A) wherein the trained graph classification model is trained by a learning process that considers confidence values assigned to each entity of a set of entities within the entity-feature-graph (Paragraphs 27, 40, 43, and 45).
The examiner notes that Salazar teaches “wherein the trained graph classification model is trained by a learning process that considers confidence values assigned to each entity of a set of entities within the entity-feature-graph” as “The training set database 245 stores one or more patient complaint-symptom datasets that are used to generate the knowledge graph 225. These datasets are further described in conjunction with FIG. 6. In some embodiments, the training set database 245 is combined with the patient information database 205” (Paragraph 27), “the medical triage assistance system 200 determines 330 the patient's symptoms based on the relevant conversation tokens. The medical triage assistance system 200 traverses the knowledge graph 225 based on the relevant conversation tokens and determines a probability and confidence level that the tokens are associated with specific symptoms. One method for generating the knowledge graph 225 is described in conjunction with FIGS. 7-8. Various complex network metrics, such as adjacency matrices and geodesic paths, may be used to traverse the knowledge graph 225. The knowledge graph 225 may also be traversed based on probabilistic modeling and detection of anchors and triplets, or deep Kalman filters, including deep learning and probabilistic modeling. Multiple symptoms can be presented to the nurse, along with the calculated probabilities and confidence levels” (Paragraph 40), “If the medical triage assistance system 200 receives a correction to the symptoms from the nurse, it can use that feedback to rebalance the connections of the knowledge graph 225 and re-score the multi-class classifier. A nurse can provide a correction by selecting the correct symptom that should have been identified, such as through a multiple-choice interface. The knowledge graph 225 is recomputed based on the correction and the recomputed knowledge graph 225 replaces the current knowledge graph 225 once a threshold improvement in performance is reached. Previous versions of the knowledge graph 225 may be stored to allow for analysis of historical data and models” (Paragraph 43), and “The medical triage assistance system 200 may also select 340 one or more specific medical protocols to recommend based on the patient's symptoms. Each medical protocol is based on one or more symptoms and is made up of a series of questions that are designed to differentiate between life-threatening conditions associated with that symptom and less urgent conditions. The medical triage assistance system 200 maps specific medical protocols to the various medical concepts of the knowledge graph 225. This mapping can be manually created, or learned (i.e., as part of the knowledge graph 225) based on existing patient cases. The medical triage assistance system 200 selects 340 the medical protocols based on confidence scoring. The medical triage assistance system 200 may present the selected 340 protocol(s) to the nurse as a recommendation and wait for approval or correction before proceeding” (Paragraph 45). The examiner further notes that a selected intervention is based off of a generated knowledge graph (i.e. the claimed undefined entity feature graph in the broadest reasonable interpretation) that is traversed/mapped via a learned process (i.e. the use of a “trained graph classification model” (which is undefined in the claims) in the broadest reasonable interpretation). Such a learned process is learned based on probabilities/confidence values of the knowledge graph.
Salazar, Pal, and Chen do not explicitly teach:
B) the confidence values indicating confidence levels with which respective ones of the entities are extracted from the at least two data streams.
Badr, however, teaches “the confidence values indicating confidence levels with which respective ones of the entities are extracted from the at least two data streams” as “if a digital image received by module 108 includes a particular content item(s) such as the Eiffel tower, and/or a dog standing in front of the Eiffel tower, then module 108 can use logic 204 to extract image features, or pixel data, that correspond to at least one of: a) the Eiffel tower, or b) the dog. Module 108 can then use label generation logic 206 to generate one or more labels (e.g., words, or text phrases) based on extracted features for Eiffel tower and dog” (Paragraph 43) and “labels that are more definitive or descriptive of particular attributes or extracted image features of an item of digital content may be assigned a higher confidence score relative to labels that more generic. For example, referencing the above extracted features for the Eiffel tower and the dog, descriptive labels such as “Eiffel” or “Eiffel tower” may receive higher confidence scores when compared to more generic labels such as “tower” or “Paris.” Likewise, descriptive labels such as “golden retriever” or “cute cocker spaniel” may receive higher confidence scores when compared to more generic labels such as “dog” or “cute dog.” (Paragraph 46)”.
The examiner further notes that although Salazar teaches probabilities/confidence values, there is no explicit teaching that such values are indicative of levels of extracted entities. Nevertheless, Badr teaches the concept of confidence values that are indicative of extracted entities from images. The combination would result in expanding Salazar to also have confidence values that are indicative of levels of extracted entities.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Badr’s would have allowed Salazar’s, Pal’s, and Chen’s to provide a method for indicating a relevance level of extracted features, as noted by Badr (Paragraph 45).
16. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Salazar et al. (U.S. PGPUB 2018/0218126), in view of Pal et al. (U.S. PGPUB 2017/0053461), and further in view of Chen et al. (CN104933839A (Machine Translation Provided)) as applied to claims 1, 5-6, 9-11, and 15-19 above, and in view of Romeo et al. (U.S. PGPUB 2015/0134088).
17. Regarding claim 7, Salazar, Pal, and Chen do not explicitly teach a computer-implemented method comprising:
A) determining based on the at least two data streams that the patient has undergone a surgery and is underactive; and
B) executing the selected intervention of adapting a therapy associated with the patient.
Romeo, however, teaches “determining based on the at least two data streams that the patient has undergone a surgery and is underactive” as “Once the patient has completed the registration process, the patient meets with the healthcare practitioner to assess the condition and determine a procedure to treat the condition. Upon determining a procedure appropriate for the patient's condition, the physician coordinates the procedure. For example, surgery can be performed and the patient provided with a post-operative brace to be worn during the healing process. The physician can also provide direction to another healthcare practitioner, such as a trainer or physical therapist, to deliver a physical therapy solution for the patient” (Paragraph 24), “The practitioner can then review the data and check on the patient's performance. If the patient is underperforming, the healthcare practitioner can call or schedule an appointment with the patient to review progress, determine if the patient is having difficulties or problems that need to be addressed, or simply to remind the patient to try harder when performing the routines. Where the patient is performing well, the practitioner may reach out and congratulate the patient, and, in some embodiments, the practitioner may have the ability to award the patient with rewards points or additional rewards points for good performance. Importantly, the practitioner uses the information to determine the progress of the patient and to determine whether a change needs to be made in the prescribed physical therapy regimen or if other follow-up treatments are required” (Paragraph 65), and “the doctor or patient can initiate a video or audio phone conference to discuss topics such as the patient's health and condition, the exercise routines, and so on. The doctor or patient can take advantage of a live video conversation to monitor the patient's performance and provide feedback. Likewise, as described in more detail below, photographs and other information can be captured and provided with the data to provide the healthcare practitioner with additional information regarding the patient's performance” (Paragraph 68) and “executing the selected intervention of adapting a therapy associated with the patient” as “Once the patient has completed the registration process, the patient meets with the healthcare practitioner to assess the condition and determine a procedure to treat the condition. Upon determining a procedure appropriate for the patient's condition, the physician coordinates the procedure. For example, surgery can be performed and the patient provided with a post-operative brace to be worn during the healing process. The physician can also provide direction to another healthcare practitioner, such as a trainer or physical therapist, to deliver a physical therapy solution for the patient” (Paragraph 24), “The practitioner can then review the data and check on the patient's performance. If the patient is underperforming, the healthcare practitioner can call or schedule an appointment with the patient to review progress, determine if the patient is having difficulties or problems that need to be addressed, or simply to remind the patient to try harder when performing the routines. Where the patient is performing well, the practitioner may reach out and congratulate the patient, and, in some embodiments, the practitioner may have the ability to award the patient with rewards points or additional rewards points for good performance. Importantly, the practitioner uses the information to determine the progress of the patient and to determine whether a change needs to be made in the prescribed physical therapy regimen or if other follow-up treatments are required” (Paragraph 65), and “the doctor or patient can initiate a video or audio phone conference to discuss topics such as the patient's health and condition, the exercise routines, and so on. The doctor or patient can take advantage of a live video conversation to monitor the patient's performance and provide feedback. Likewise, as described in more detail below, photographs and other information can be captured and provided with the data to provide the healthcare practitioner with additional information regarding the patient's performance” (Paragraph 68).
The examiner further notes that the secondary reference of Romeo teaches the concept of modifying the rehab (i.e. therapy) of a post-op underperforming patient based off of received data. The combination would result in altering interventions based off of underperformance in Salazar.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Romeo’s would have allowed Salazar’s, Pal’s, and Chen’s to provide a method for improving the outcomes of surgery, as noted by Romeo (Paragraph 03).
Allowable Subject Matter
18. Claims 3 and 13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Specifically, although the prior art (See Salazar) teaches the processing of multiple streams of patient data for subsequent output recommendations, the detailed claim language directed towards the specific transformation of the defined entity-feature graph into an embedding space via a process that uses distances between entity pairs in that space to encode probabilities that those pairs are the same is not found in the prior art in conjunction with the rest of the limitations of the parent claims.
Dependent claims 4 and 14 are deemed allowable for depending on the deemed allowable subject matter of dependent claims 3 and 13 respectively.
Claim 8 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Specifically, although the prior art (See Romeo) teaches the automated modification of therapy of a patient recovering from surgery, the detailed claim language directed towards the specific determination of a patient watching TV and subsequently intervening to increase the difficulty of sports equipment of that patient is not found in the prior art in conjunction with the rest of the limitations of the parent claims.
Response to Arguments
19. Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument (See newly applied art of Chen).
Applicant's arguments filed on 06/24/2026 have been fully considered but they are not persuasive.
Applicants argue on Page 11 that “While Salazar does describe a database storing conversation records between a patient and healthcare professional, where the conversation records can include text transcriptions and video calls, as well as screen shots from a video call or images submitted by a patient, Salazar is silent as to using sensors. For example, the Examiner appears to map whatever device is being used by the patient to conduct a conversation with the healthcare professional to the one or more sensors of claim 1”. However, the examiner wishes to refer to Salazar which states “The patient information database 205 stores information about patients (i.e., users) of the medical triage assistance system 200. Patient information may include identification information, demographics, conversation records, symptoms, medical history, and health insurance claims data. Identification information may be an identifier within the medical triage assistance system 200 associated with the patient, or an identifier from a more ubiquitous entity, like a driver's license or social security number. Conversation records allow the medical triage assistance system 200 access to conversations between the patient and a healthcare professional or the medical triage assistance system 200. These conversations may take place via chat or text messages, or via audio or video calls. For chat or text messages, the conversation record contains the messages and an indication of who sent the message. For an audio or video call, the conversation record is a transcript and may also include who said what. Screenshots (from a video call) or images submitted by the patient may also be included in conversation records. For example, the patient may submit images of a rash. In some embodiments, a conversation between the patient and the healthcare professionals are routed through the medical triage assistance system 200. In this embodiment, the medical triage assistance system 200 is able to record the conversation while it is taking place” (Paragraph 19). The examiner further notes that a camera and/or microphone for a video call (which is then stored as screenshots and transcripts) teaches the claimed one or more sensors in the broadest reasonable interpretation.
Applicants argue on Page 12 that “the combination of Salazar and Pal is improper as the Office has not provided sufficient reasoning for combining Salazar and Pal, and relies on impermissible hindsight gleaned from Applicant's specification. For example, the Office Action asserts that it would have been obvious to one of ordinary skill in the art before the effective filing data of the instant invention to combine the teachings of the cited references because the teachings of Pal would have allowed Salazar to provide a method for improving response delivery to accident detection, pointing to paragraph [0004] of Pal. See Office Action, page 34. However, as noted above, Salazar and Pal are directed to quite different problems, as Salazar is primarily directed to processing conversational data to derive medically relevant tokens that are mapped via a knowledge graph to symptoms, to derive recommended treatments. Pal, on the other hand, uses data collected from a vehicle after an event to determine a severity of an accident to then take further actions such as calling an ambulance or collecting more data to help with aid responses. Salazar has nothing to do with transportation, vehicles or accidents, and is rather based on analyzing conversations between a patient and health care provider without any regard to a location of an event, which is irrelevant in Salazar. There is no apparent reason, absent impermissible hindsight gleaned from Applicant's specification, why one of ordinary skill in the art would seek to modify the teachings of Salazar using Pal which is in a disparate field of technology and would not provide any benefit to providing a treatment recommendation in accordance with the teachings of Salazar”. However, in response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). Indeed, the examiner provided a cited motivation with a rational underpinning for the obviousness rejection. Moreover, both Salazar and Pal deal with the selection of interventions to “patients”. Thus, Salazar and Pal can be combined, in contrast to the assertions from the applicants.
Conclusion
20. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. PGPUB 2019/0251480 issued to Duran et al. on 14 August 2019. The subject matter disclosed therein is pertinent to that of claims 1-20 (e.g., methods to process sensor data).
U.S. PGPUB 2019/0148025 issued to Stone et al. on 16 May 2019. The subject matter disclosed therein is pertinent to that of claims 1-20 (e.g., methods to process sensor data).
21. 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.
Contact Information
22. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mahesh Dwivedi whose telephone number is (571) 272-2731. The examiner can normally be reached on Monday to Friday 8:20 am – 4:40 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached (571) 272-4085. The fax number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Mahesh Dwivedi
Primary Examiner
Art Unit 2168
July 12, 2026
/MAHESH H DWIVEDI/Primary Examiner, Art Unit 2168
Prosecution Insights