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 .
Claim Rejections - 35 USC § 103
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.
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.
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.
Claim(s) 1-3, 5, 7-15, 17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pub No. US 2024/0323663 A1 to William et. al. (William).
In Reference to Claim 1
A method comprising:
receiving search event data representative of a search event (see at least William Fig.1 and paragraph [0066] “In some embodiments, the emergency notification is an HTTP post or another type of Internet-based message containing information regarding the emergency request. In some embodiments, the emergency notification is an SMS message (data or text), a multimedia message, etc. In some embodiments, the emergency notification includes a location (e.g., a device-based hybrid location) generated by or for the electronic device 110, which may be current or historical location. In some embodiments, in response to detecting an emergency request generated or sent by the electronic device 110, the computer program is configured to deliver user data to the emergency management system (EMS) 120”);
accessing real-time target physical condition data from a target device, wherein the real-time target physical condition data is representative of one or more real-time target physical condition items (see at least William Fig.2 and paragraph [0083] and [0084] “FIG. 2 depicts an embodiment of an Emergency Clearinghouse 250 for storing and retrieving emergency data. In some embodiments, the clearinghouse 250 includes a set of ingestion modules 258 (also referred to as “ingestion modules”) and a set of retrieval modules 259 (also referred to as “retrieval modules”). The set of ingestion modules 258 is configured to receive various forms of emergency data from various emergency data sources 262, such as an electronic device 210A or a third-party server system 260 (hereinafter, “third-party server”). In some embodiments, an electronic device 210A is a communication device (e.g., a mobile phone), a wearable device (e.g., a smartwatch), or an internet of things (IoT) device (e.g., a smart speaker) that can communicate with one or more of the ingestion modules within the set of ingestion modules 258. In some embodiments, a third-party server 260 stores data that is not generated by or stored within an electronic device. For example, in some embodiments, a third-party server includes a database of static medical information that can be sent to the clearinghouse during an emergency. In some embodiments, when the emergency management system 120 detects an emergency (e.g., when a person calls 9-1-1), the clearinghouse can query an emergency data source 262 for emergency data regarding the emergency. For example, in some embodiments, in response to detecting a 9-1-1 call made from a mobile phone, the additional data ingestion module 252 (as described below) sends a query including the phone number of the mobile phone to a third-party server 260 that stores static medical information” and “The third-party server 260 can then return any available medical information associated with the phone number of the mobile phone to the additional data ingestion module. In some embodiments, multiple ingestion modules within the set of ingestion modules can receive emergency data for a single emergency. For example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the mobile phone can send a device-based hybrid location to the location ingestion module 251 (as described below) and demographic data (as described above) to the additional data ingestion module 252. In some embodiments, the clearinghouse can receive emergency data from multiple emergency data sources 262 for a single emergency. For example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the clearinghouse can receive a location from the mobile phone (such as through the location ingestion module 251) and a heartrate from a smartwatch that the person is wearing (such as through additional data ingestion module 252). Or for example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the clearinghouse can receive a location from the mobile phone and medical information associated with the person from a third-party server 260”);
generating a target physical condition interface component (such as 1407, 1305, 1428, “medical information”) based on the real-time target physical condition data, wherein the target physical condition interface component comprises the one or more real-time target physical condition items (see at least William Figs.13B, 13C and 14-15 and [0177], [0178] and [0180], “In some embodiments, wherein a device that generated an emergency alert for which an incident is created within the jurisdictional awareness view is a mobile device and relocating in real time, the device's location is updated within the interactive map of the jurisdictional awareness view in real time. For example, when the emergency alert (including an initial location) is generated and transmitted to (or detected by) the emergency management system (EMS), the EMS can determine an appropriate ESP to receive the emergency alert and any data associated with the emergency alert and then automatically push the emergency alert and any data associated with the emergency alert to the ESP through the jurisdictional awareness view of the emergency response application (as described above). The emergency response application can then create an incident associated with the emergency alert within the jurisdictional awareness view, such as by listing an incident 1312 in the incident queue 1310 and displaying a corresponding incident location 1324 within the interactive map 1320. If the device sends updated location to the EMS, the EMS can automatically push the updated location to the emergency response application. The emergency response application can then update the incident location 1324 by moving the incident location 1324 within the interactive map 1320 to the location of the updated location received from the device. In some embodiments, the emergency response application displays the location associated with all incidents 1312 listed in the incident queue 1310 and tracks the location associated with each incident 1312 in real time simultaneously” and “In some embodiments, a user of the emergency response application is enabled to access a single incident view from the jurisdictional awareness view. In some embodiments, the single incident view is accessed by the user selecting an incident location or an incident listed on the incident queue. FIG. 13C illustrates the selection of an incident 1312C in the incident queue 1310 to enter the single incident view. In some embodiments, the single incident view enlarges or moves the user's interactive map 1320 to detail the environment around the incident location 1324 (in the example depicted by FIG. 13C, incident location 1324C) corresponding to the selected incident 1312 (in the example depicted by FIG. 13C, incident 1312C). In some embodiments, enhanced location data 1303 or additional data (as depicted by FIG. 14C) is available in the single incident view.” and “In another example, in some embodiments, the single incident view enables a user of the emergency response application to access one or more data layers. In some embodiments, a data overlay comprises an additional source of information. Examples of such information sources include IoT sensors (e.g., temperature sensor, camera/video camera), first responder devices (e.g., police vehicle console), wearable sensors (e.g., heart monitor), third party databases, and other relevant sources. In some embodiments, the jurisdictional awareness view is configured to be customizable to show one or more data overlays (or none) based on user configured settings. For example, FIG. 14B depicts the single incident view of the jurisdictional awareness view displaying a data layer. In this example, the jurisdictional awareness view provides a menu of data layers 1428. In this example, the menu of data layers 1428 includes toggles for four different data layers: historic locations (as described above), live traffic, weather, and social media. In the example depicted by FIG. 14B, incident 1412B has been selected and a user has selected the live traffic data layer to be turned on. In response, the jurisdictional awareness view has displayed traffic levels on the streets and roads around the incident location 1424 associated with incident 1412B. In this example, four different levels of traffic are displayed within the interactive map: none, light, medium, and heavy. Traffic levels around the location of an emergency may be particularly helpful for emergency service providers in dispatching first responders to the location. In some embodiments, the weather data layer displays weather conditions in the vicinity of an incident location 1424. In some embodiments, the social media data layer displays relevant social media data, such as social media posts regarding emergencies in the vicinity of an incident location 1424. The emergency response application may provide any type of data layer that offers emergency service providers helpful information in responding to emergencies”, William do not explicitly show that the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) containing one or more real-time target physical condition items. However, William does teach that when clicking the search event access interface (such as 1312, 1320, 1324, 1412 or “additional info”, etc), the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) render and also teaches that any type of data layer that offers emergency service providers helpful information (such as heart rate of the monitoring person) in responding to emergencies can be rendered therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that system of William rendering the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) includes the real time physical monitoring data such as heart rates of the monitoring persons when clicking the search event access interface (such as 1312, 1320, 1324, 1412 or “additional info”, etc) in order to provide helpful information to the emergency responders when assisting the monitoring person);
generating a search event access interface component (1312, 1320, 1324, 1412 or “additional info”, etc), wherein the search event access interface component comprises one or more access links (see at least William Figs.13B, 13C and 14 and [0173] “In some embodiments, each incident location 1324 is automatically updated or changed. In some embodiments, the incident location 1324 is updated or changed to reflect response status of secondary response agencies, such as the fire department or police department. In some embodiments, the incident location 1324 is updated or changed to reflect response status at a PSAP. For example, the incident location 1324 may be flashing to indicate that no user at the PSAP has attended to the associated incident 1312. In another example, the incident location 1324 may automatically change color to indicate that a first responder has been dispatched to the associated emergency location. In another example, an incident location 1324 may automatically change to reflect that an emergency is no longer active, or the caller has exited the jurisdictional geofence of the PSAP. In some embodiments, the user is enabled to toggle on and off incident location customization preferences. In some embodiments, the user is enabled to display device identifier data (e.g. phone numbers) adjacent to an incident location 1324. For example, as depicted in FIG. 13B, an additional data overlay associated with incident 1312C (e.g., the associated device identifier and the time and date that the associated emergency alert was received) is displayed directly above the incident location 1324C associated with incident 1312C. In some embodiments, data associated with an incident is displayed within the interactive map 1320 in response to the incident 1312 or associated incident location 1324 being selected within the incident queue 1310 or interactive map 1320. In some embodiments, a user can select an incident 1312 or an incident location 1324 by clicking on or hovering over the incident 1312 or incident location 1324”); and
causing the target physical condition interface component (1407, 1305, 1428, “medical information”) to be rendered to a search event operations interface in response to a selection of a target physical condition access link of the one or more access links (see at least William Figs.13B, 13C and 14-15 and [0033], [1073] and “c) in response to receiving selection of the incident location associated with the device identifier, display the additional emergency data within the GUI. In some embodiments, the additional emergency data comprises at least one of caller information, sensor data, emergency contact information, emergency indication, and medical information. In some embodiments, selection of the incident location associated with the device identifier comprises clicking on or hovering over the first incident location”, “For example, as depicted in FIG. 13B, an additional data overlay associated with incident 1312C (e.g., the associated device identifier and the time and date that the associated emergency alert was received) is displayed directly above the incident location 1324C associated with incident 1312C. In some embodiments, data associated with an incident is displayed within the interactive map 1320 in response to the incident 1312 or associated incident location 1324 being selected within the incident queue 1310 or interactive map 1320. In some embodiments, a user can select an incident 1312 or an incident location 1324 by clicking on or hovering over the incident 1312 or incident location 132”).
In Reference to Claim 2
The method of claim 1 (see rejection to claim 1 above), wherein the target device comprises a wearable device (see at least William Fig.1 and paragraph [0060] “In certain embodiments, disclosed herein are devices, systems, and methods for managing emergency data for emergency response. FIG. 1A depicts diagrams of (i) an electronic device 110 and (ii) an emergency management system (EMS) 120. In some embodiments, the electronic device 110 is a digital processing device such as a communication device (e.g., mobile or cellular phone, computer, laptop, etc.). In some embodiments, the electronic device is a wearable device (e.g., a smartwatch). In some embodiments, the electronic device is an Internet of Things (IoT) device, such as a home assistant (e.g., an Amazon Echo) or a connected smoke detector (e.g., a Nest Protect smoke and carbon monoxide alarm). In some embodiments, the electronic device is a walkie-talkie or two-way radio”).
In Reference to Claim 3
The method of claim 1 (see rejection to claim 1 above), further comprising: initiating performance of one or more search event responsive actions (see at least William Fig.1 and paragraph [0065] “In some embodiments, in response to detecting an emergency request for assistance (e.g., a native dial 9-1-1 call) generated or sent by the electronic device 110, the computer program is configured to deliver an emergency notification to the EMS 120”).
In Reference to Claim 5
The method of claim 3 (see rejection to claim 3 above), wherein initiating performance of one or more search event responsive actions comprises transmitting an instruction message to an enterprise device (120) (see at least William Fig.1 and paragraph [0065] “In some embodiments, in response to detecting an emergency request for assistance (e.g., a native dial 9-1-1 call) generated or sent by the electronic device 110, the computer program is configured to deliver an emergency notification to the EMS 120”).
In Reference to Claim 7
The method of claim 3 (see rejection to claim 3 above), wherein initiating performance of one or more search event responsive actions comprises: detecting a cellular tower in proximity to the target device (see at least William Fig.1 and paragraph [0237] “Modern communication devices, for example, smart phones, tablet computers, wearable communication devices, smart sensor devices and/or systems are often equipped with a variety of features for determining location information of the communication device using, for example, GPS, or triangulation with cellular phone towers. Modern communication devices also often include functionality to store data regarding a user of the communication device, for example, health information about the user”); and causing an aircraft to navigate towards the cellular tower in response to detecting the cellular tower in proximity to the target device (see at least William Fig.1 and paragraph [0190] and [0224] “Alternatively, a similar screenshot may be displayed at an ESP computer system which has received the emergency request for assistance for dispatching responders to the emergency location and for monitoring the emergency response. For example, an ESP dispatcher may share a similar geographical map of medical assets on display for emergency responders in the field. The geospatial view may include the emergency location 1683 on the geographical map and the ESP users view assets that are in proximity to the emergency location for sending the response. If current location of the responders is available, the movement of response assets (e.g., fire trucks sent to the scene) can also be monitored on the map” and “As used herein, a public safety service (PSS) refers to a local, state, or federal government agency or institution that is responsible for providing safety, security, or medical services to members of the public. Examples of public safety services include fire departments, police departments, and hospitals. In some embodiments, public safety services additionally include public safety answering points (PSAPs). A PSAP refers to a call center responsible for answering calls to an emergency telephone number for police, firefighting, and ambulance services. Trained telephone operators (also referred to as call-takers) are also usually responsible for dispatching these emergency services. The Federal Communications Commission (FCC) of the United States government maintains a PSAP registry. The registry lists PSAPs by an FCC assigned identification number, PSAP Name, State, County, City, and provides information on any type of record change and the reason for updating the record. The FCC updates the registry periodically as it receives additional information. In some embodiments, the ESP identifier or PSAP identifier comprises the FCC identification of the agency” since it is very well known that the emergency responders such as ambulance or firetruck can include aircraft such as helicopters therefore it would have been obvious that the emergency responders could send aircraft such as ambulance helicopter to the emergency location).
In Reference to Claim 8
The method of claim 1 (see rejection to claim 1 above), further comprising: generating a target proximity interface component, wherein the target proximity interface component comprises one or more target proximity action items (see at least William Fig.14 and paragraph [0181] “For example, in some embodiments, the jurisdictional awareness view displays the location of available emergency services within a variable proximity to one or more incident locations 1424 (e.g., an emergency services data layer). In some embodiments, the jurisdictional awareness view displays the location of one or more first responders. In some embodiments, the location of a first responder that is assigned to and/or actively responding to an incident 1412 is displayed. In some embodiments, the location of the first responder is provided in real-time. In some embodiments, an estimated time to arrival and/or distance to arrival are displayed (e.g., calculated using the shortest or fastest path between the first responder and the incident location). In some embodiments, the emergency response application enables an ESP to coordinate the dispatch of emergency responders to incident locations 1412, so as to reduce response times and improve the allocation of resources. In some embodiments, the emergency response application is updated in response to the dispatch of a first responder to an incident location 1412. In some embodiments, the emergency response application is updated manually or automatically. In some embodiments, the jurisdictional view is used improve the coordination of first responder resources during large scale emergencies such as natural disasters, industrial accidents, and acts of terror”)
In Reference to Claim 9
The method of claim 1 (see rejection to claim 1 above), further comprising: generating a historical search event interface component, wherein the historical search event interface component comprises one or more historical search event action items (see at least William Fig.14 and paragraph [0179] “In some embodiments, the single incident view enables a user to access various additional features. For example, in some embodiments, the single incident view enables the viewing of past location data (also referred to as “historic location data”) through the use of a toggle button 1305A or menu selection 1305B. FIG. 14A illustrates the use of the past location data feature. In some embodiments, toggling the historic locations button 1405 allows the user to view the past locations 1426 (also referred to as “historic locations”) associated with a particular incident 1412 listed in the incident queue 1410. As mentioned above, in some embodiments, the emergency response application can receive location updates regarding an incident 1412 and update the corresponding incident location 1424 accordingly. By selecting to see historic location data for a particular incident 1412, a user can see past locations 1426 associated with an incident 1412 as well as the current location (represented by the incident location 1424) associated with the incident 1412, as depicted by FIG. 14A. FIG. 14A depicts five incidents 1412 listed in the incident queue, incidents 1412A-1412E. In the example depicted by FIG. 14A, incident 1412B has been selected to bring up a single caller view for the incident 1412B. In response, the interactive map 1420 has zoomed in on the incident location 1424 associated with incident 1412B. Additionally, the user has selected to see historic locations 1426 by toggling the historic locations button 1405. In response, the interactive map 1420 now displays markers for historic locations 1426 associated with the incident 1412B. In some embodiments, the emergency response application displays a predetermined maximum number of past or historic locations 1426. For example, in some embodiments, the emergency response application displays no more than three historic locations associated with a particular incident 1412. In some embodiments, the emergency response application displays all of the historic locations 1426 associated with a particular incident 1412. In some embodiments, date and time is displayed when the user selects or moves the cursor over a past location data marker. In some embodiments, past location markers and the current location marker are displayed. In some embodiments, past location markers are automatically denoted or visibly distinct from current location markers. For example, past location markers may be denoted as shades of color, wherein more distant location markers are lighter shades, while the current location marker is the darkest shade of the color, or a different color. For example, as depicted in FIG. 14A, the current (e.g., most recent) location marker is depicted in black while the past location markers are depicted in white”).
In Reference to Claim 10
The method of claim 1 (see rejection to claim 1 above), further comprising: generating a target device activity interface component, wherein the target device activity interface component comprises one or more target device activity items (see at least William Fig.14 and paragraph [0233] “As used herein, “sensor data” refers to information obtained or provided by one or more sensors. In some instances, a sensor is associated with a device (e.g., user has a communication device with a data link via Bluetooth with a wearable sensor, such as, for example, a heart rate monitor or a pedometer). Accordingly, in some embodiments, the device obtains sensor data from the sensor (e.g., heart rate from the heart rate monitor or distance traveled from the pedometer). In some instances, the sensor data is relevant to an emergency situation (e.g., heart rate during a cardiac emergency event). In some embodiments, a sensor and/or sensor device comprises an acoustic sensor, a breathalyzer, a carbon dioxide sensor, a carbon monoxide sensor, an infrared sensor, an oxygen sensor, an ozone monitor, a pH sensor, a smoke detector, a current sensor (e.g., detects electric current in a wire), a magnetometer, a metal detector, a radio direction finder, a voltage detector, an air flow meter, an anemometer, a flow sensor, a gas meter, a water meter, a Geiger counter, an altimeter, an air speed indicator, a depth gauge, a gyroscope, a compass, an odometer, a shock detector (e.g., on a football helmet to measure impact), a barometer, a pressure gauge, a thermometer, a proximity sensor, a motion detector (e.g., in a home security system), an occupancy sensor, or any combination thereof, and in some embodiments, sensor data comprises information obtained from any of the preceding sensors. In some embodiments, one or more sensors are physically separate from a user device. In further embodiments, the one or more sensors authorize the user device to obtain sensor data. In further embodiments, the one or more sensors provide or send sensor data to the user device autonomously. In some embodiments, the user device and the one or more sensors belong to the same group of devices, wherein member devices are authorized to share data. In some embodiments, a user device comprises one or more sensors (e.g., user device is a wearable device having a sensor or sensing component)”).
In Reference to Claim 11
The method of claim 1 (see rejection to claim 1 above), further comprising: generating a search zone interface component (see Fig. 16), wherein the search zone interface component comprises a horizontal view sub-interface component and a vertical view sub-interface component; and causing the search zone interface component to be rendered to a search zone interface (see at least William Fig.16 and paragraph [0188] and [0189] “FIG. 16 illustrates a non-limiting example of a graphical user interface displaying the returned results under a jurisdictional awareness view. For example, an ESP member (e.g. emergency responder, a police beat within the jurisdiction of the police station) may have entered a location using the geospatial query box 1688. In another example, the emergency location 1683 may be the geospatial query. The geospatial query map may be latitude-longitude, an address, a jurisdictional view of assets, a proximity radius from the emergency location, a proximity radius from landmarks, etc”, “The geofence 1670 (e.g. a jurisdiction or sub-jurisdiction) corresponding to the credentials of the ESP member or responder may be displayed as a data overlay on a geographical map. Emergency locations outside the sub-jurisdiction (or alternatively in the geofence buffer zone) may be depicted using a different symbol (e.g. triangle 1692). In some cases, the responder 1680 may be able to view different types of events such as fire emergencies (big circles 1682) and medical emergencies (small circles 1684) within its sub-jurisdiction. The responder 1680 may click on an emergency for additional information regarding the emergency. In addition, the responder 1680 may respond or dispatch to the emergency using 1688. Although not shown, the responder 1680 may mark off after the emergency has been responded to or cancel an emergency. Various types of emergencies, assets etc. can be viewed using the options 1673”).
In Reference to Claim 12
The method of claim 1 (see rejection to claim 1 above), further comprising: accessing static target physical condition data representative of one or more static target physical condition items, wherein the target physical condition interface component further comprises the one or more static target physical condition items (see at least William Fig.14 and paragraph [0083] “FIG. 2 depicts an embodiment of an Emergency Clearinghouse 250 for storing and retrieving emergency data. In some embodiments, the clearinghouse 250 includes a set of ingestion modules 258 (also referred to as “ingestion modules”) and a set of retrieval modules 259 (also referred to as “retrieval modules”). The set of ingestion modules 258 is configured to receive various forms of emergency data from various emergency data sources 262, such as an electronic device 210A or a third-party server system 260 (hereinafter, “third-party server”). In some embodiments, an electronic device 210A is a communication device (e.g., a mobile phone), a wearable device (e.g., a smartwatch), or an internet of things (IoT) device (e.g., a smart speaker) that can communicate with one or more of the ingestion modules within the set of ingestion modules 258. In some embodiments, a third-party server 260 stores data that is not generated by or stored within an electronic device. For example, in some embodiments, a third-party server includes a database of static medical information that can be sent to the clearinghouse during an emergency. In some embodiments, when the emergency management system 120 detects an emergency (e.g., when a person calls 9-1-1), the clearinghouse can query an emergency data source 262 for emergency data regarding the emergency. For example, in some embodiments, in response to detecting a 9-1-1 call made from a mobile phone, the additional data ingestion module 252 (as described below) sends a query including the phone number of the mobile phone to a third-party server 260 that stores static medical information”).
In Reference to Claim 13
The method of claim 1 (see rejection to claim 1 above), wherein the real-time target physical condition data is accessed from the target device in response to receiving the search event data (see at least William Fig.14 and paragraph [0097] “However, in some embodiments, the EMS can “push” emergency data from the clearinghouse 250 to the emergency response application (i.e., the EMS can send emergency data to the emergency response application 260 without receiving an emergency data request). In some embodiments, the EMS pushes emergency data to the emergency response application 260 using an emergency data subscription system. Using the emergency data subscription, a recipient (or potential recipient) of emergency data from the clearinghouse 250 can subscribe to the clearinghouse 250 for a particular device identifier, user identifier, or ESP account (hereinafter, “subscription”). After subscribing to a subscription, the recipient (e.g., an ESP) may automatically receive updates regarding the subscription without first sending an emergency data request. For example, in some embodiments, if an ESP subscribes to a phone number, whenever the clearinghouse 250 receives updated emergency data associated with the phone number, the clearinghouse 250 can automatically send the updated emergency data associated with the phone number to the ESP (e.g., through the emergency response application 260), without first receiving an emergency data request including the phone number. For example, in some embodiments, if a recipient is subscribed to a particular phone number, and the clearinghouse 250 receives a new or updated location associated with the particular phone number, the clearinghouse 250 will instantly and automatically push the new or updated location associated with the particular phone number to the recipient the moment that the new or updated location is received by the clearinghouse 250, without the recipient having to send an emergency data request. In some embodiments, when an ESP or ESP personnel accesses the emergency response application 260 at a computing device associated with the ESP or ESP personnel, the EMS establishes a websocket connection with the computing device in order to push emergency data regarding a subscription to which the ESP or ESP personnel is subscribed to the emergency response application 260. WebSocket is a type of computer communications protocol. A websocket connection is a longstanding internet connection between a client and a server that allows for bidirectional communication between the client and server without the client needing to send data requests to the server, which differentiates the WebSocket computer communications protocol from other types of computer communications protocols such as the HyperTextual Transfer Protocol (HTTP). The WebSocket protocol is often used by chat clients to facilitate user to user webchats. In some embodiments, the EMS establishes a websocket connection with a computing device (e.g., an ESP console 130) in response to receiving an emergency data request. In some embodiments, the EMS establishes a websocket connection with an ESP console when an ESP personnel logs into the emergency response application 260 at the ESP console. In some embodiments, the EMS establishes a websocket connection with a responder device when an ESP personnel logs into the emergency response application 260 at the responder device. In some embodiments a websocket connection established between the EMS and a computing device associated with ESP personnel is maintained by the EMS for the duration of the ESP personnel's log-in session”).
In Reference to Claim 14
An apparatus comprising memory and one or more processors communicatively coupled to the memory, the one or more processors configured to:
receive search event data representative of a search event (see at least William Fig.1 and paragraph [0066] “In some embodiments, the emergency notification is an HTTP post or another type of Internet-based message containing information regarding the emergency request. In some embodiments, the emergency notification is an SMS message (data or text), a multimedia message, etc. In some embodiments, the emergency notification includes a location (e.g., a device-based hybrid location) generated by or for the electronic device 110, which may be current or historical location. In some embodiments, in response to detecting an emergency request generated or sent by the electronic device 110, the computer program is configured to deliver user data to the emergency management system (EMS) 120”);
access real-time target physical condition data from a target device, wherein the real-time target physical condition data is representative of one or more real-time target physical condition items (see at least William Fig.2 and paragraph [0083] and [0084] “FIG. 2 depicts an embodiment of an Emergency Clearinghouse 250 for storing and retrieving emergency data. In some embodiments, the clearinghouse 250 includes a set of ingestion modules 258 (also referred to as “ingestion modules”) and a set of retrieval modules 259 (also referred to as “retrieval modules”). The set of ingestion modules 258 is configured to receive various forms of emergency data from various emergency data sources 262, such as an electronic device 210A or a third-party server system 260 (hereinafter, “third-party server”). In some embodiments, an electronic device 210A is a communication device (e.g., a mobile phone), a wearable device (e.g., a smartwatch), or an internet of things (IoT) device (e.g., a smart speaker) that can communicate with one or more of the ingestion modules within the set of ingestion modules 258. In some embodiments, a third-party server 260 stores data that is not generated by or stored within an electronic device. For example, in some embodiments, a third-party server includes a database of static medical information that can be sent to the clearinghouse during an emergency. In some embodiments, when the emergency management system 120 detects an emergency (e.g., when a person calls 9-1-1), the clearinghouse can query an emergency data source 262 for emergency data regarding the emergency. For example, in some embodiments, in response to detecting a 9-1-1 call made from a mobile phone, the additional data ingestion module 252 (as described below) sends a query including the phone number of the mobile phone to a third-party server 260 that stores static medical information” and “The third-party server 260 can then return any available medical information associated with the phone number of the mobile phone to the additional data ingestion module. In some embodiments, multiple ingestion modules within the set of ingestion modules can receive emergency data for a single emergency. For example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the mobile phone can send a device-based hybrid location to the location ingestion module 251 (as described below) and demographic data (as described above) to the additional data ingestion module 252. In some embodiments, the clearinghouse can receive emergency data from multiple emergency data sources 262 for a single emergency. For example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the clearinghouse can receive a location from the mobile phone (such as through the location ingestion module 251) and a heartrate from a smartwatch that the person is wearing (such as through additional data ingestion module 252). Or for example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the clearinghouse can receive a location from the mobile phone and medical information associated with the person from a third-party server 260”);
generate a target physical condition interface component (such as 1407, 1305, 1428, “medical information”) based on the real-time target physical condition data, wherein the target physical condition interface component comprises the one or more real-time target physical condition items (see at least William Figs.13B, 13C and 14-15 and [0177], [0178] and [0180], “In some embodiments, wherein a device that generated an emergency alert for which an incident is created within the jurisdictional awareness view is a mobile device and relocating in real time, the device's location is updated within the interactive map of the jurisdictional awareness view in real time. For example, when the emergency alert (including an initial location) is generated and transmitted to (or detected by) the emergency management system (EMS), the EMS can determine an appropriate ESP to receive the emergency alert and any data associated with the emergency alert and then automatically push the emergency alert and any data associated with the emergency alert to the ESP through the jurisdictional awareness view of the emergency response application (as described above). The emergency response application can then create an incident associated with the emergency alert within the jurisdictional awareness view, such as by listing an incident 1312 in the incident queue 1310 and displaying a corresponding incident location 1324 within the interactive map 1320. If the device sends updated location to the EMS, the EMS can automatically push the updated location to the emergency response application. The emergency response application can then update the incident location 1324 by moving the incident location 1324 within the interactive map 1320 to the location of the updated location received from the device. In some embodiments, the emergency response application displays the location associated with all incidents 1312 listed in the incident queue 1310 and tracks the location associated with each incident 1312 in real time simultaneously” and “In some embodiments, a user of the emergency response application is enabled to access a single incident view from the jurisdictional awareness view. In some embodiments, the single incident view is accessed by the user selecting an incident location or an incident listed on the incident queue. FIG. 13C illustrates the selection of an incident 1312C in the incident queue 1310 to enter the single incident view. In some embodiments, the single incident view enlarges or moves the user's interactive map 1320 to detail the environment around the incident location 1324 (in the example depicted by FIG. 13C, incident location 1324C) corresponding to the selected incident 1312 (in the example depicted by FIG. 13C, incident 1312C). In some embodiments, enhanced location data 1303 or additional data (as depicted by FIG. 14C) is available in the single incident view.” and “In another example, in some embodiments, the single incident view enables a user of the emergency response application to access one or more data layers. In some embodiments, a data overlay comprises an additional source of information. Examples of such information sources include IoT sensors (e.g., temperature sensor, camera/video camera), first responder devices (e.g., police vehicle console), wearable sensors (e.g., heart monitor), third party databases, and other relevant sources. In some embodiments, the jurisdictional awareness view is configured to be customizable to show one or more data overlays (or none) based on user configured settings. For example, FIG. 14B depicts the single incident view of the jurisdictional awareness view displaying a data layer. In this example, the jurisdictional awareness view provides a menu of data layers 1428. In this example, the menu of data layers 1428 includes toggles for four different data layers: historic locations (as described above), live traffic, weather, and social media. In the example depicted by FIG. 14B, incident 1412B has been selected and a user has selected the live traffic data layer to be turned on. In response, the jurisdictional awareness view has displayed traffic levels on the streets and roads around the incident location 1424 associated with incident 1412B. In this example, four different levels of traffic are displayed within the interactive map: none, light, medium, and heavy. Traffic levels around the location of an emergency may be particularly helpful for emergency service providers in dispatching first responders to the location. In some embodiments, the weather data layer displays weather conditions in the vicinity of an incident location 1424. In some embodiments, the social media data layer displays relevant social media data, such as social media posts regarding emergencies in the vicinity of an incident location 1424. The emergency response application may provide any type of data layer that offers emergency service providers helpful information in responding to emergencies”, William do not explicitly show that the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) containing one or more real-time target physical condition items. However, William does teach that when clicking the search event access interface (such as 1312, 1320, 1324, 1412 or “additional info”, etc), the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) render and also teaches that any type of data layer that offers emergency service providers helpful information (such as heart rate of the monitoring person) in responding to emergencies can be rendered therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that system of William rendering the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) includes the real time physical monitoring data such as heart rates of the monitoring persons when clicking the search event access interface (such as 1312, 1320, 1324, 1412 or “additional info”, etc) in order to provide helpful information to the emergency responders when assisting the monitoring person);
generate a search event access interface component (1312, 1320, 1324, 1412 or “additional info”, etc), wherein the search event access interface component comprises one or more access links (see at least William Figs.13B, 13C and 14 and [0173] “In some embodiments, each incident location 1324 is automatically updated or changed. In some embodiments, the incident location 1324 is updated or changed to reflect response status of secondary response agencies, such as the fire department or police department. In some embodiments, the incident location 1324 is updated or changed to reflect response status at a PSAP. For example, the incident location 1324 may be flashing to indicate that no user at the PSAP has attended to the associated incident 1312. In another example, the incident location 1324 may automatically change color to indicate that a first responder has been dispatched to the associated emergency location. In another example, an incident location 1324 may automatically change to reflect that an emergency is no longer active, or the caller has exited the jurisdictional geofence of the PSAP. In some embodiments, the user is enabled to toggle on and off incident location customization preferences. In some embodiments, the user is enabled to display device identifier data (e.g. phone numbers) adjacent to an incident location 1324. For example, as depicted in FIG. 13B, an additional data overlay associated with incident 1312C (e.g., the associated device identifier and the time and date that the associated emergency alert was received) is displayed directly above the incident location 1324C associated with incident 1312C. In some embodiments, data associated with an incident is displayed within the interactive map 1320 in response to the incident 1312 or associated incident location 1324 being selected within the incident queue 1310 or interactive map 1320. In some embodiments, a user can select an incident 1312 or an incident location 1324 by clicking on or hovering over the incident 1312 or incident location 1324”); and
cause the target physical condition interface component (1407, 1305, 1428, “medical information”) to be rendered to a search event operations interface in response to a selection of a target physical condition access link of the one or more access links (see at least William Figs.13B, 13C and 14-15 and [0033], [1073] and “c) in response to receiving selection of the incident location associated with the device identifier, display the additional emergency data within the GUI. In some embodiments, the additional emergency data comprises at least one of caller information, sensor data, emergency contact information, emergency indication, and medical information. In some embodiments, selection of the incident location associated with the device identifier comprises clicking on or hovering over the first incident location”, “For example, as depicted in FIG. 13B, an additional data overlay associated with incident 1312C (e.g., the associated device identifier and the time and date that the associated emergency alert was received) is displayed directly above the incident location 1324C associated with incident 1312C. In some embodiments, data associated with an incident is displayed within the interactive map 1320 in response to the incident 1312 or associated incident location 1324 being selected within the incident queue 1310 or interactive map 1320. In some embodiments, a user can select an incident 1312 or an incident location 1324 by clicking on or hovering over the incident 1312 or incident location 132”).
In Reference to Claim 15
The apparatus of claim 14 (see rejection to claim 14 above), wherein the one or more processors are further configured to: initiate performance of one or more search event responsive actions (see at least William Fig.1 and paragraph [0065] “In some embodiments, in response to detecting an emergency request for assistance (e.g., a native dial 9-1-1 call) generated or sent by the electronic device 110, the computer program is configured to deliver an emergency notification to the EMS 120”).
In Reference to Claim 17
The apparatus of claim 15 (see rejection to claim 15 above), wherein initiating performance of one or more search event responsive actions comprises the one or more processors being further configured to transmit an instruction message to an enterprise device (120) (see at least William Fig.1 and paragraph [0065] “In some embodiments, in response to detecting an emergency request for assistance (e.g., a native dial 9-1-1 call) generated or sent by the electronic device 110, the computer program is configured to deliver an emergency notification to the EMS 120”).
In Reference to Claim 19
The apparatus of claim 15 (see rejection to claim 15 above), wherein initiating performance of one or more search event responsive actions comprises the one or more processors being further configured to: detect a cellular tower in proximity to the target device (see at least William Fig.1 and paragraph [0237] “Modern communication devices, for example, smart phones, tablet computers, wearable communication devices, smart sensor devices and/or systems are often equipped with a variety of features for determining location information of the communication device using, for example, GPS, or triangulation with cellular phone towers. Modern communication devices also often include functionality to store data regarding a user of the communication device, for example, health information about the user”); and cause an aircraft to navigate towards the cellular tower in response to detecting the cellular tower in proximity to the target device (see at least William Fig.1 and paragraph [0190] and [0224] “Alternatively, a similar screenshot may be displayed at an ESP computer system which has received the emergency request for assistance for dispatching responders to the emergency location and for monitoring the emergency response. For example, an ESP dispatcher may share a similar geographical map of medical assets on display for emergency responders in the field. The geospatial view may include the emergency location 1683 on the geographical map and the ESP users view assets that are in proximity to the emergency location for sending the response. If current location of the responders is available, the movement of response assets (e.g., fire trucks sent to the scene) can also be monitored on the map” and “As used herein, a public safety service (PSS) refers to a local, state, or federal government agency or institution that is responsible for providing safety, security, or medical services to members of the public. Examples of public safety services include fire departments, police departments, and hospitals. In some embodiments, public safety services additionally include public safety answering points (PSAPs). A PSAP refers to a call center responsible for answering calls to an emergency telephone number for police, firefighting, and ambulance services. Trained telephone operators (also referred to as call-takers) are also usually responsible for dispatching these emergency services. The Federal Communications Commission (FCC) of the United States government maintains a PSAP registry. The registry lists PSAPs by an FCC assigned identification number, PSAP Name, State, County, City, and provides information on any type of record change and the reason for updating the record. The FCC updates the registry periodically as it receives additional information. In some embodiments, the ESP identifier or PSAP identifier comprises the FCC identification of the agency” since it is very well known that the emergency responders such as ambulance or firetruck can include aircraft such as helicopters therefore it would have been obvious that the emergency responders could send aircraft such as ambulance helicopter to the emergency location).
In Reference to Claim 20
A computer program product comprising at least one non-transitory computer-readable storage medium having computer program code stored thereon that, in execution with at least one processor, configures the computer program product for:
receiving search event data representative of a search event (see at least William Fig.1 and paragraph [0066] “In some embodiments, the emergency notification is an HTTP post or another type of Internet-based message containing information regarding the emergency request. In some embodiments, the emergency notification is an SMS message (data or text), a multimedia message, etc. In some embodiments, the emergency notification includes a location (e.g., a device-based hybrid location) generated by or for the electronic device 110, which may be current or historical location. In some embodiments, in response to detecting an emergency request generated or sent by the electronic device 110, the computer program is configured to deliver user data to the emergency management system (EMS) 120”);
accessing real-time target physical condition data from a target device, wherein the real-time target physical condition data is representative of one or more real-time target physical condition items (see at least William Fig.2 and paragraph [0083] and [0084] “FIG. 2 depicts an embodiment of an Emergency Clearinghouse 250 for storing and retrieving emergency data. In some embodiments, the clearinghouse 250 includes a set of ingestion modules 258 (also referred to as “ingestion modules”) and a set of retrieval modules 259 (also referred to as “retrieval modules”). The set of ingestion modules 258 is configured to receive various forms of emergency data from various emergency data sources 262, such as an electronic device 210A or a third-party server system 260 (hereinafter, “third-party server”). In some embodiments, an electronic device 210A is a communication device (e.g., a mobile phone), a wearable device (e.g., a smartwatch), or an internet of things (IoT) device (e.g., a smart speaker) that can communicate with one or more of the ingestion modules within the set of ingestion modules 258. In some embodiments, a third-party server 260 stores data that is not generated by or stored within an electronic device. For example, in some embodiments, a third-party server includes a database of static medical information that can be sent to the clearinghouse during an emergency. In some embodiments, when the emergency management system 120 detects an emergency (e.g., when a person calls 9-1-1), the clearinghouse can query an emergency data source 262 for emergency data regarding the emergency. For example, in some embodiments, in response to detecting a 9-1-1 call made from a mobile phone, the additional data ingestion module 252 (as described below) sends a query including the phone number of the mobile phone to a third-party server 260 that stores static medical information” and “The third-party server 260 can then return any available medical information associated with the phone number of the mobile phone to the additional data ingestion module. In some embodiments, multiple ingestion modules within the set of ingestion modules can receive emergency data for a single emergency. For example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the mobile phone can send a device-based hybrid location to the location ingestion module 251 (as described below) and demographic data (as described above) to the additional data ingestion module 252. In some embodiments, the clearinghouse can receive emergency data from multiple emergency data sources 262 for a single emergency. For example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the clearinghouse can receive a location from the mobile phone (such as through the location ingestion module 251) and a heartrate from a smartwatch that the person is wearing (such as through additional data ingestion module 252). Or for example, in some embodiments, when a person calls 9-1-1 from a mobile phone, the clearinghouse can receive a location from the mobile phone and medical information associated with the person from a third-party server 260”);
generating a target physical condition interface component (such as 1407, 1305, 1428, “medical information”) based on the real-time target physical condition data, wherein the target physical condition interface component comprises the one or more real-time target physical condition items (see at least William Figs.13B, 13C and 14-15 and [0177], [0178] and [0180], “In some embodiments, wherein a device that generated an emergency alert for which an incident is created within the jurisdictional awareness view is a mobile device and relocating in real time, the device's location is updated within the interactive map of the jurisdictional awareness view in real time. For example, when the emergency alert (including an initial location) is generated and transmitted to (or detected by) the emergency management system (EMS), the EMS can determine an appropriate ESP to receive the emergency alert and any data associated with the emergency alert and then automatically push the emergency alert and any data associated with the emergency alert to the ESP through the jurisdictional awareness view of the emergency response application (as described above). The emergency response application can then create an incident associated with the emergency alert within the jurisdictional awareness view, such as by listing an incident 1312 in the incident queue 1310 and displaying a corresponding incident location 1324 within the interactive map 1320. If the device sends updated location to the EMS, the EMS can automatically push the updated location to the emergency response application. The emergency response application can then update the incident location 1324 by moving the incident location 1324 within the interactive map 1320 to the location of the updated location received from the device. In some embodiments, the emergency response application displays the location associated with all incidents 1312 listed in the incident queue 1310 and tracks the location associated with each incident 1312 in real time simultaneously” and “In some embodiments, a user of the emergency response application is enabled to access a single incident view from the jurisdictional awareness view. In some embodiments, the single incident view is accessed by the user selecting an incident location or an incident listed on the incident queue. FIG. 13C illustrates the selection of an incident 1312C in the incident queue 1310 to enter the single incident view. In some embodiments, the single incident view enlarges or moves the user's interactive map 1320 to detail the environment around the incident location 1324 (in the example depicted by FIG. 13C, incident location 1324C) corresponding to the selected incident 1312 (in the example depicted by FIG. 13C, incident 1312C). In some embodiments, enhanced location data 1303 or additional data (as depicted by FIG. 14C) is available in the single incident view.” and “In another example, in some embodiments, the single incident view enables a user of the emergency response application to access one or more data layers. In some embodiments, a data overlay comprises an additional source of information. Examples of such information sources include IoT sensors (e.g., temperature sensor, camera/video camera), first responder devices (e.g., police vehicle console), wearable sensors (e.g., heart monitor), third party databases, and other relevant sources. In some embodiments, the jurisdictional awareness view is configured to be customizable to show one or more data overlays (or none) based on user configured settings. For example, FIG. 14B depicts the single incident view of the jurisdictional awareness view displaying a data layer. In this example, the jurisdictional awareness view provides a menu of data layers 1428. In this example, the menu of data layers 1428 includes toggles for four different data layers: historic locations (as described above), live traffic, weather, and social media. In the example depicted by FIG. 14B, incident 1412B has been selected and a user has selected the live traffic data layer to be turned on. In response, the jurisdictional awareness view has displayed traffic levels on the streets and roads around the incident location 1424 associated with incident 1412B. In this example, four different levels of traffic are displayed within the interactive map: none, light, medium, and heavy. Traffic levels around the location of an emergency may be particularly helpful for emergency service providers in dispatching first responders to the location. In some embodiments, the weather data layer displays weather conditions in the vicinity of an incident location 1424. In some embodiments, the social media data layer displays relevant social media data, such as social media posts regarding emergencies in the vicinity of an incident location 1424. The emergency response application may provide any type of data layer that offers emergency service providers helpful information in responding to emergencies”, William do not explicitly show that the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) containing one or more real-time target physical condition items. However, William does teach that when clicking the search event access interface (such as 1312, 1320, 1324, 1412 or “additional info”, etc), the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) render and also teaches that any type of data layer that offers emergency service providers helpful information (such as heart rate of the monitoring person) in responding to emergencies can be rendered therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention that system of William rendering the target physical condition interfaces (such as 1407, 1305, 1428, “medical information”) includes the real time physical monitoring data such as heart rates of the monitoring persons when clicking the search event access interface (such as 1312, 1320, 1324, 1412 or “additional info”, etc) in order to provide helpful information to the emergency responders when assisting the monitoring person);
generating a search event access interface component (1312, 1320, 1324, 1412 or “additional info”, etc), wherein the search event access interface component comprises one or more access links (see at least William Figs.13B, 13C and 14 and [0173] “In some embodiments, each incident location 1324 is automatically updated or changed. In some embodiments, the incident location 1324 is updated or changed to reflect response status of secondary response agencies, such as the fire department or police department. In some embodiments, the incident location 1324 is updated or changed to reflect response status at a PSAP. For example, the incident location 1324 may be flashing to indicate that no user at the PSAP has attended to the associated incident 1312. In another example, the incident location 1324 may automatically change color to indicate that a first responder has been dispatched to the associated emergency location. In another example, an incident location 1324 may automatically change to reflect that an emergency is no longer active, or the caller has exited the jurisdictional geofence of the PSAP. In some embodiments, the user is enabled to toggle on and off incident location customization preferences. In some embodiments, the user is enabled to display device identifier data (e.g. phone numbers) adjacent to an incident location 1324. For example, as depicted in FIG. 13B, an additional data overlay associated with incident 1312C (e.g., the associated device identifier and the time and date that the associated emergency alert was received) is displayed directly above the incident location 1324C associated with incident 1312C. In some embodiments, data associated with an incident is displayed within the interactive map 1320 in response to the incident 1312 or associated incident location 1324 being selected within the incident queue 1310 or interactive map 1320. In some embodiments, a user can select an incident 1312 or an incident location 1324 by clicking on or hovering over the incident 1312 or incident location 1324”); and
causing the target physical condition interface component (1407, 1305, 1428, “medical information”) to be rendered to a search event operations interface in response to a selection of a target physical condition access link of the one or more access links (see at least William Figs.13B, 13C and 14-15 and [0033], [1073] and “c) in response to receiving selection of the incident location associated with the device identifier, display the additional emergency data within the GUI. In some embodiments, the additional emergency data comprises at least one of caller information, sensor data, emergency contact information, emergency indication, and medical information. In some embodiments, selection of the incident location associated with the device identifier comprises clicking on or hovering over the first incident location”, “For example, as depicted in FIG. 13B, an additional data overlay associated with incident 1312C (e.g., the associated device identifier and the time and date that the associated emergency alert was received) is displayed directly above the incident location 1324C associated with incident 1312C. In some embodiments, data associated with an incident is displayed within the interactive map 1320 in response to the incident 1312 or associated incident location 1324 being selected within the incident queue 1310 or interactive map 1320. In some embodiments, a user can select an incident 1312 or an incident location 1324 by clicking on or hovering over the incident 1312 or incident location 132”).
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over William in view of Pub No. US 2017/0344707 A1 to Patel (Patel).
In Reference to Claim 4
William teaches (except for the bolded and italic recitations below):
The method of claim 3 (see rejection to claim 3 above), wherein initiating performance of one or more search event responsive actions comprises transmitting an action message to the target device (see at least William Figs.13-16 and paragraphs 66, 83-84, 173, 177-178 and 180).
William is silent (bolded and italic recitations above) as to transmitting an action message to the target device. However, it is known in the art before the effective filing date of the claimed invention to transmitting an action message to the target device. For example, Patel teaches to transmitting an action message to the target device. Patel further teaches that performing such step provides helpful information to the person (or patient) and conserves network resources and computing resources due to efficiencies associated with ensuring that appropriate information is provided to appropriate devices at appropriate times (see at least Patel Figs. 17-18 and 20-22 and paragraphs 66, 80-82, 91). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of William to perform the step of transmitting an action message to the target device as taught by Patel in order to provide helpful information to the person (or patient) and conserves network resources and computing resources due to efficiencies associated with ensuring that appropriate information is provided to appropriate devices at appropriate times.
In Reference to Claim 16
William teaches (except for the bolded and italic recitations below):
The apparatus of claim 15 (see rejection to claim 15 above), wherein initiating performance of one or more search event responsive actions comprises the one or more processors being further configured to transmit an action message to the target device (see at least William Figs.13-16 and paragraphs 66, 83-84, 173, 177-178 and 180).
William is silent (bolded and italic recitations above) as to transmitting an action message to the target device. However, it is known in the art before the effective filing date of the claimed invention to transmitting an action message to the target device. For example, Patel teaches to transmitting an action message to the target device. Patel further teaches that performing such step provides helpful information to the person (or patient) and conserves network resources and computing resources due to efficiencies associated with ensuring that appropriate information is provided to appropriate devices at appropriate times (see at least Patel Figs. 17-18 and 20-22 and paragraphs 66, 80-82, 91). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of William to perform the step of transmitting an action message to the target device as taught by Patel in order to provide helpful information to the person (or patient) and conserves network resources and computing resources due to efficiencies associated with ensuring that appropriate information is provided to appropriate devices at appropriate times.
Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over William in view of US Patent No. 7,920,679 B1 to Naim et. al (Naim).
In Reference to Claim 6
William teaches (except for the bolded and italic recitations below):
The method of claim 3 (see rejection to claim 3 above), wherein initiating performance of one or more search event responsive actions comprises: detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices (see at least William Figs.13-16 and paragraphs 66, 83-84, 173, 177-178 and 180).
William is silent (bolded and italic recitations above) as to detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices. However, it is known in the art before the effective filing date of the claimed invention to detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices. For example, Naim teaches to detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices (steps 202 and 203). Naim further teaches that performing such steps provides rendering assistance, evacuating the area, making room for or assisting emergency personnel, etc (see at least Naim Figs. 1-5 and column 3 lines 8-67, column 4 lines 1-51). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of William with the steps of detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices as taught by Naim in order to provide rendering assistance, evacuating the area, making room for or assisting emergency personnel, etc.
In Reference to Claim 18
William teaches (except for the bolded and italic recitations below):
The apparatus of claim 15 (see rejection to claim 15 above), wherein initiating performance of one or more search event responsive actions comprises the one or more processors being further configured to: detect one or more secondary devices in proximity to the target device; and transmit an alert message to the one or more secondary devices (see at least William Figs.13-16 and paragraphs 66, 83-84, 173, 177-178 and 180).
William is silent (bolded and italic recitations above) as to detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices. However, it is known in the art before the effective filing date of the claimed invention to detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices. For example, Naim teaches to detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices (steps 202 and 203). Naim further teaches that performing such steps provides rendering assistance, evacuating the area, making room for or assisting emergency personnel, etc (see at least Naim Figs. 1-5 and column 3 lines 8-67, column 4 lines 1-51). Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of William with the steps of detecting one or more secondary devices in proximity to the target device; and transmitting an alert message to the one or more secondary devices as taught by Naim in order to provide rendering assistance, evacuating the area, making room for or assisting emergency personnel, etc.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent No. 12,072,907 B1 Haq et. al. (Haq) teaches GUI with data visualization and timestamped.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON DONGPA LEE whose telephone number is (571)270-3525. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aniss Chad can be reached at (571) 270-3832. 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.
/BRANDON D LEE/Primary Examiner, Art Unit 3662 May 7, 2026
Prosecution Insights