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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of US 12185184. Although the claims at issue are not identical, they are not patentably distinct from each other because all the claims in the pending application are transparently found in US 12185184 with obvious wording variations.
Claim 1:
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Patent claims 1 and 7 recite receiving an emergency alert, obtaining and providing the emergency location to an emergency dispatch center, determining a responder forecast, providing the forecast for display, determining whether a current responder location is available, and calculating or approximating the responder distance or arrival time based on that determination. Using a known responder-facility location when the current responder location is unavailable is an obvious variation of performing the approximation in the claimed.
Claim 2:
Claim 2 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Patent claims 1 and 7 claim determining and approximating a responder forecast. Comparing the number of ongoing emergencies with available resources merely uses known workload and availability information to improve that forecast and would have been an obvious implementation of the claimed approximation.
Claim 3:
Claim 3 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Computing a time multiplier from the relationship between ongoing emergencies and available resources is a obvious technique for adjusting the estimated arrival time already claimed by patent claims 1 and 7.
Claim 4:
Claim 4 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 7, and 8 of U.S. Patent No. 12,185,184. Patent claim 8 expressly recites obtaining an emergency type, including medical, fire, police, or car-accident emergencies. Selecting an appropriate responder facility according to the emergency type is an obvious use of that information in generating the forecast claimed by claims 1 and 7.
Claim 5:
Claim 5 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Patent claim 1 already obtains emergency-response information for responders within a vicinity of the emergency location and claim 7 approximates the forecast when current responder locations are unavailable. Considering multiple responder facilities within that vicinity is an obvious way to perform the claimed approximation.
Claim 6:
Claim 6 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Once multiple possible responder facilities are identified, estimating the distance or arrival time from each facility is a predictable implementation of the responder-forecast approximation claimed by patented claims 1 and 7.
Claim 7:
Claim 7 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Averaging multiple distance or arrival-time estimates is a conventional mathematical technique for producing a single representative estimate and is not patentably distinct from the responder-forecast approximation claimed by patent claims 1 and 7.
Claim 8:
Claim 8 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Using a navigation API to calculate distance or travel time is a predictable implementation of the distance or arrival-time calculation required by patent claims 1 and 7.
Claim 9:
Claim 9 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 5, and 7 of U.S. Patent No. 12,185,184. Patent claim 1 provides the responder forecast for display on a communication device, and claim 5 provides the forecast to a computing device of an authorized user. Displaying the estimated distance or arrival time on the user electronic device is therefore an obvious variation.
Claim 10:
Claim 10 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Patent claim 7 expressly identifies responder distance and estimated time of arrival as responder-forecast information. Calculating both expressly identified values, rather than only one, would have been an obvious variation.
Claim 11:
Claim 11 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Ongoing emergencies, driving conditions, and weather are known factors affecting responder travel time. Applying those factors to the distance or arrival-time approximation claimed by patent claims 1 and 7 would have been obvious.
Claim 12:
Claim 12 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 7 of U.S. Patent No. 12,185,184. Patent claim 7 requires approximating the distance or arrival time when current responder-location information is unavailable. Using historical regional response times when facility-location information is also unavailable is an obvious alternative source for making that approximation.
Claim 13:
Claim 13 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 6, and 7 of U.S. Patent No. 12,185,184. Patent claim 6 recites current responder-location information, and claim 7 calculates responder distance or arrival time when that information is available. Using a navigation API to perform the expressly claimed calculation is an obvious implementation.
Claim 14:
Claim 14 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Patent claims 11 and 17 recite the corresponding emergency-management system, including receiving an emergency alert, obtaining and providing the emergency location, determining and displaying a responder forecast, determining whether current responder-location information is available, and calculating or approximating responder distance or arrival time. Using a responder-facility location to perform the approximation is an obvious implementation of the system already claimed.
Claim 15:
Claim 15 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Comparing ongoing emergencies with available resources merely applies known workload information to the forecast approximation claimed by patent claims 11 and 17.
Claim 16:
Claim 16 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Computing a time multiplier based on emergency workload and available resources is a known mathematical technique for adjusting the estimated arrival time claimed by patent claims 11 and 17.
Claim 17:
Claim 17 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Identifying several responder facilities near the emergency location is an obvious way to obtain information for the responder-forecast approximation required by patent claims 11 and 17.
Claim 18:
Claim 18 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Once multiple responder facilities are identified, calculating an estimate from each facility is a predictable implementation of the responder-forecast approximation claimed by patent claims 11 and 17.
Claim 19:
Claim 19 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Averaging the estimates is a conventional mathematical technique for producing a representative responder forecast and does not make the claimed system patentably distinct.
Claim 20:
Claim 20 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 11 and 17 of U.S. Patent No. 12,185,184. Using a navigation API is an obvious implementation for calculating the responder distances or arrival times already required by patent claims 11 and 17.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of US 11425529. Although the claims at issue are not identical, they are not patentably distinct from each other because all the claims in the pending application are transparently found in US 11425529 with obvious wording variations.
Claim 1:
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Patent claims 1 and 14 recite an emergency-management system and corresponding method that obtain an emergency alert and current device location and provide emergency information to an appropriate requesting party.
Patent claim 3 further requires the system to calculate an estimated arrival time for a responder dispatched to that location. The current claim specifies a particular facility-location fallback for performing that responder-arrival calculation.
Claim 2:
Claim 2 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Comparing ongoing emergencies with available resources is a predictable way of refining the responder estimated-arrival-time calculation required by patent claim 3.
Claim 3:
Claim 3 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. A time multiplier based on emergency workload and available resources is a predictable mathematical technique of the responder estimated-arrival-time calculation claimed in patent claim 3.
Claim 4:
Claim 4 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Selecting the responder facility according to the type or severity of the emergency is an obvious preliminary step for determining which responder's arrival time should be calculated under patent claim 3.
Claim 5:
Claim 5 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Identifying multiple responder facilities near the emergency location is an asserted predictable way of obtaining location information for the responder-arrival-time calculation of patent claim 3.
Claim 6:
Claim 6 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Calculating an estimate from each possible responder facility is a predictable extension of calculating the responder arrival time under patent claim 3.
Claim 7:
Claim 7 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Averaging multiple estimates is a conventional mathematical technique for producing a single representative arrival-time estimate.
Claim 8:
Claim 8 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Employing a navigation API is an obvious implementation for calculating the responder estimated arrival time required by patent claim 3.
Claim 9:
Claim 9 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Patent claim 1 returns emergency information to a requesting party, while claim 3 calculates responder arrival information. Providing the calculated information for display on an electronic device is expected use of that information.
Claim 10:
Claim 10 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Calculating both distance and arrival time merely provides two closely related forms of responder-arrival information instead of the estimated arrival time expressly claimed by patent claim 3.
Claim 11:
Claim 11 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Emergency workload, driving conditions, and weather are known factors that affect travel time. Applying them to the responder-arrival calculation claimed in patent claim 3 is an obvious refinement.
Claim 12:
Claim 12 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Historical regional response times provide a predictable alternative basis for calculating the responder arrival time required by patent claim 3 when more specific location information is unavailable.
Claim 13:
Claim 13 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1, 3, and 14 of U.S. Patent No. 11,425,529. Patent claim 3 expressly calculates the arrival time of a responder dispatched to the current location. Using the responder's known location and a navigation API is an obvious implementation of that calculation.
Claim 14:
Claim 14 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Patent claim 1 recites an emergency-management system with the same processor, memory, network, emergency-alert, and emergency-location framework. Patent claim 3 further requires calculating a responder estimated arrival time. The current claim specifies a particular fallback technique for performing that calculation and transmitting the resulting forecast for display.
Claim 15:
Claim 15 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Comparing workload with available emergency resources is a predictable refinement of the responder estimated-arrival-time calculation required by patent claim 3.
Claim 16:
Claim 16 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Using a time multiplier based on workload and available resources is a predictable mathematical implementation of the arrival-time calculation claimed in patent claim 3.
Claim 17:
Claim 17 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Identifying several responder facilities near the emergency is an asserted predictable manner of obtaining information for the responder-arrival calculation required by patent claim 3.
Claim 18:
Claim 18 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Calculating estimates from each identified facility is a predictable extension of the responder estimated-arrival-time calculation claimed by patent claim 3.
Claim 19:
Claim 19 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Averaging multiple estimates is a conventional mathematical technique for producing a representative responder-arrival estimate.
Claim 20:
Claim 20 is rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1 and 3 of U.S. Patent No. 11,425,529. Using a navigation API is an obvious implementation for calculating responder distances or estimated arrival times under patent claim 3.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 4-6, 11, 12, 14, 15, 17 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pfeffer (US 20090284348, hereinafter “Pfeffer”).
Regarding claim 1, Pfeffer discloses,
A method of providing a responder forecast for an emergency situation by an emergency management system (task management system 100 can be configured to identify incidents, develop one or more incident scenarios to resolve the incidents, and implement the one or more incident scenarios by assigning tasks to one or more responders through dispatch requests. An incident can refer to any event for which it is desirable to have the assistance of a responder, [0028]; [0032; [0038]), the method comprising:
receiving an emergency alert from a user electronic device regarding an emergency situation (the incident information can be received through any method, including a telephone call, an e-mail, a text message, a satellite image, a voice message, a coded message, a distress signal from the mobile device of a responder [0073]-[0074]), the emergency alert including an emergency location (The transmitter may also include GPS or other location-based information such that the transmitter can provide location information to the task management system [0074]);
providing the emergency location to an emergency dispatch center for responding to the emergency situation (The dispatcher can initiate a new incident by entering the incident information or taking control of an incident initiated by a third party such as a responder or e-911. In an exemplary embodiment, the incident information can be manually entered into the task management system by a dispatcher through a dispatcher interface [0076] and [0079]-[0080]);
determining, based at least on the emergency location, a responder forecast for one or more responders to respond to the emergency situation (Dispatch engine 175 can interact with mapping engine 180 and/or assets databases 190 to generate the dispatch. Dispatch engine 175 can use mapping engine 180 to identify the locations of responders relative to a location of the incident (i.e., incident location) [0042]-[0044]), wherein determining the responder forecast includes:
determining whether a current location of the one or more responders is known (mobile device 105 may have a global positioning system (GPS) antenna allowing mobile device 105 to continuously be tracked with a small margin of error. Mobile device 110 may not have a GPS antenna but maybe configured for network-based location identification through triangulation or other such methods offered through network 120. Mobile device 115 may not have a GPS antenna or the ability to use network-based location identification, but may be associated with one or more predefined, fixed positions identified by a responder associated with mobile device 115 [0033]; [0063]);
responsive to determining whether a current location of the one or more responders is not known (mobile device 300 may also include assisted-GPS (A-GPS) functionality such that the location of mobile device 300 can potentially be determined while the responder is inside a building or in any other area in which GPS location may be non-functional or inaccurate. Any A-GPS algorithms known to those of skill in the art may be used. If the mobile device of a responder is not GPS-enabled, the responder can be asked to enter pre-defined location information such as home address, work address, etc [0063]), determining whether at least one facility location of at least one responder facility is known (The responder profile can include the proposed responder's name, home address, work address, mobile device characteristics and capabilities, skills, abilities, qualifications, an identification of equipment in possession of the responder and/or accessible by the responder, location(s) of the identified equipment, mode(s) of transportation, an identification of agencies or other organizations (i.e., fire department, policing agency, etc.) with which the responder is registered, an identification of the responder's roles within any registered agencies or other organizations (i.e., ambulance driver, ambulance repair man, etc.), and/or any other information regarding the responder which can be used by a dispatch engine to generate a dispatch in response to an incident [0053]); and
responsive to determining whether the at least one facility location of the at least one responder facility is known, estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location ( If the mobile device of a responder is not GPS-enabled, the responder can be asked to enter pre-defined location information such as home address, work address, etc. such that the task management system can have an approximation of the responder's whereabouts. The responder may also be asked for his/her location at any given time. The responder may also pre-program a plurality of locations (i.e., locations 1-9) such that the responder can rapidly indicate to which location he/she is nearest [0063]; The responder database can include information regarding the responder's mode of transportation (i.e., bicycle, foot, motorcycle, scooter, vehicle, four wheel drive vehicle, public transportation, etc.), and dispatch engine 175 can use the mode of transportation information along with the current location of the responder and any other known factors (i.e., bad weather, bad traffic, rush hour, etc.) to determine the amount of time it should take the responder to arrive at the incident location [0044]; the task management system can also determine an expected arrival time of the responder at the incident location. The expected arrival time can be based on the responder's current mode of transportation, the weather, traffic, and/or the ability of the responder disobey traffic laws. The task management system can also estimate times that the responder will pass various locations along his/her route to the incident location [0094]); and
transmitting at least a portion of the responder forecast to be displayed on the user electronic device or on another electronic device (FIG. 7, dynamic map identifies an incident location of a traffic accident and the locations of responders within the area/perimeter of the incident. As described in more detail below, the dispatcher can use this information to identify traffic slow downs, to provide support to responders en route, and/or to adjust the dispatch based on responder progress [0101]-[0103]).
Regarding claim 2, Pfeffer discloses,
wherein estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location includes comparing a number of ongoing emergencies with available emergency resources (Resource manager 601 also includes information regarding a level of alert for the geographic region, shift information relevant to responders, agencies, and/or equipment, etc. The level of alert can be based on the weather, the number of active incidents, the number of available resources, information received from various agencies regarding potential threats, unusual events occurring in the area that may require support (i.e., parades, sporting events, festivals, etc.), etc. If the level of alert exceeds a predetermined threshold, the dispatcher or task management system can send out requests for additional responders to make themselves available [0077]; the task management system can also determine an expected arrival time of the responder at the incident location. The expected arrival time can be based on the responder's current mode of transportation, the weather, traffic, and/or the ability of the responder disobey traffic laws. The task management system can also estimate times that the responder will pass various locations along his/her route to the incident location [0094]).
Regarding claim 4, Pfeffer discloses,
determining the at least one responder facility, wherein the at least one responder facility is determined based on at least one of a type of the emergency situation or the severity of the emergency situation (Scenario database 185 can include pre-programmed optimal responses based on incident information such as type of incident, location of incident, time of day, time of year, current weather, whether the incident occurred on a holiday, the number of persons involved in the incident, the equipment needed to deal with the incident, etc [0039]; A process similar to that described in operations 540 through 572 with respect to the responder queue can be used to go through the equipment queue to ensure that adequate equipment is dispatched to the incident. For example, an ambulance may be listed in the equipment queue and the dispatch sent to an ambulance service located closest to the incident location [0100]).
Regarding claim 5, Pfeffer discloses,
wherein the step of determining whether at least one facility location of at least one responder facility is known comprises determining a plurality of responder facilities within a predefined vicinity of the emergency location and determining whether a plurality of facility locations of the plurality of responder facilities are known (dispatch engine 175 can identify a geographic area surrounding an incident location from which responders will be requested. Alternatively, the area can be a predetermined range, such as x square kilometers from the incident location. Mapping engine 180, which can be part of a comprehensive geographic information system, can have numerous functions, including providing directions to responders, identifying alternate routes based on traffic or weather, providing aerial photographs, identifying topography, etc [0042]; A process similar to that described in operations 540 through 572 with respect to the responder queue can be used to go through the equipment queue to ensure that adequate equipment is dispatched to the incident. For example, an ambulance may be listed in the equipment queue and the dispatch sent to an ambulance service located closest to the incident location [0100])).
Regarding claim 6, Pfeffer discloses,
wherein the step of estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location comprises estimating at least one of a distance or time of arrival from each of the plurality of responder facilities to the emergency location to provide a plurality of estimated distances or times of arrival (dispatch engine 175 can identify a geographic area surrounding an incident location from which responders will be requested. Alternatively, the area can be a predetermined range, such as x square kilometers from the incident location. Mapping engine 180, which can be part of a comprehensive geographic information system, can have numerous functions, including providing directions to responders, identifying alternate routes based on traffic or weather, providing aerial photographs, identifying topography, etc….. The incident effectiveness can be specific to each incident, and can be based on a plurality of factors, including an amount of time it will take the responder to travel to the incident location. The responder database can include information regarding the responder's mode of transportation [0042]-[0044]; A process similar to that described in operations 540 through 572 with respect to the responder queue can be used to go through the equipment queue to ensure that adequate equipment is dispatched to the incident. For example, an ambulance may be listed in the equipment queue and the dispatch sent to an ambulance service located closest to the incident location [0100]).
Regarding claim 11, Pfeffer discloses,
wherein estimating a distance or time of arrival from the at least one facility location to the emergency location takes into account one or more of ongoing emergencies, current driving conditions, or weather (Mapping engine 180, which can be part of a comprehensive geographic information system, can have numerous functions, including providing directions to responders, identifying alternate routes based on traffic or weather, providing aerial photographs, identifying topography…. dispatch engine 175 can use the mode of transportation information along with the current location of the responder and any other known factors (i.e., bad weather, bad traffic, rush hour, etc.) to determine the amount of time it should take the responder to arrive at the incident location.).
Regarding claim 12, Pfeffer discloses, responsive to determining whether the at least one facility location of the at least one responder facility is not known, determine an estimated distance or time of arrival based on historical emergency response times for a region containing the emergency location ( remote database 140 may be a patient medical history repository for providing responders with up-to-date medical conditions of individuals in need of assistance. Remote database 140 can also be a satellite database that provides overview images of an incident location, a mapping database that provides maps of the incident location, a hazmat database with information regarding chemicals and/or chemical spills, a toxic poisons database, an informational database with medical treatment information, a traffic database that provides stored and/or up-to-date information regarding traffic at and around the incident location, a criminal records database [0031]).
Regarding claim 14, Pfeffer discloses,
An emergency management system comprising at least one processor, a memory, a network element, and a computer program including instructions executable by the at least one processor to create an application configured to perform operations (task management system 100 can be configured to identify incidents, develop one or more incident scenarios to resolve the incidents, and implement the one or more incident scenarios by assigning tasks to one or more responders through dispatch requests. An incident can refer to any event for which it is desirable to have the assistance of a responder, [0028]; [0032; [0038]) comprising:
receiving an emergency alert from a user electronic device regarding an emergency situation (the incident information can be received through any method, including a telephone call, an e-mail, a text message, a satellite image, a voice message, a coded message, a distress signal from the mobile device of a responder [0073]-[0074]), the emergency alert including an emergency location (The transmitter may also include GPS or other location-based information such that the transmitter can provide location information to the task management system [0074]);
providing the emergency location to an emergency dispatch center for responding to the emergency situation (The dispatcher can initiate a new incident by entering the incident information or taking control of an incident initiated by a third party such as a responder or e-911. In an exemplary embodiment, the incident information can be manually entered into the task management system by a dispatcher through a dispatcher interface [0076] and [0079]-[0080]);
determining, based at least on the emergency location, a responder forecast for one or more responders to respond to the emergency situation (Dispatch engine 175 can interact with mapping engine 180 and/or assets databases 190 to generate the dispatch. Dispatch engine 175 can use mapping engine 180 to identify the locations of responders relative to a location of the incident (i.e., incident location) [0042]-[0044]), wherein determining the responder forecast includes:
determining whether a current location of the one or more responders is known (mobile device 105 may have a global positioning system (GPS) antenna allowing mobile device 105 to continuously be tracked with a small margin of error. Mobile device 110 may not have a GPS antenna but maybe configured for network-based location identification through triangulation or other such methods offered through network 120. Mobile device 115 may not have a GPS antenna or the ability to use network-based location identification, but may be associated with one or more predefined, fixed positions identified by a responder associated with mobile device 115 [0033]; [0063]);
responsive to determining whether a current location of the one or more responders is not known (mobile device 300 may also include assisted-GPS (A-GPS) functionality such that the location of mobile device 300 can potentially be determined while the responder is inside a building or in any other area in which GPS location may be non-functional or inaccurate. Any A-GPS algorithms known to those of skill in the art may be used. If the mobile device of a responder is not GPS-enabled, the responder can be asked to enter pre-defined location information such as home address, work address, etc [0063]), determining whether at least one facility location of at least one responder facility is known (The responder profile can include the proposed responder's name, home address, work address, mobile device characteristics and capabilities, skills, abilities, qualifications, an identification of equipment in possession of the responder and/or accessible by the responder, location(s) of the identified equipment, mode(s) of transportation, an identification of agencies or other organizations (i.e., fire department, policing agency, etc.) with which the responder is registered, an identification of the responder's roles within any registered agencies or other organizations (i.e., ambulance driver, ambulance repair man, etc.), and/or any other information regarding the responder which can be used by a dispatch engine to generate a dispatch in response to an incident [0053]); and
responsive to determining whether the at least one facility location of the at least one responder facility is known, estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location ( If the mobile device of a responder is not GPS-enabled, the responder can be asked to enter pre-defined location information such as home address, work address, etc. such that the task management system can have an approximation of the responder's whereabouts. The responder may also be asked for his/her location at any given time. The responder may also pre-program a plurality of locations (i.e., locations 1-9) such that the responder can rapidly indicate to which location he/she is nearest [0063]; The responder database can include information regarding the responder's mode of transportation (i.e., bicycle, foot, motorcycle, scooter, vehicle, four wheel drive vehicle, public transportation, etc.), and dispatch engine 175 can use the mode of transportation information along with the current location of the responder and any other known factors (i.e., bad weather, bad traffic, rush hour, etc.) to determine the amount of time it should take the responder to arrive at the incident location [0044]; the task management system can also determine an expected arrival time of the responder at the incident location. The expected arrival time can be based on the responder's current mode of transportation, the weather, traffic, and/or the ability of the responder disobey traffic laws. The task management system can also estimate times that the responder will pass various locations along his/her route to the incident location [0094]); and
transmitting at least a portion of the responder forecast to be displayed on the user electronic device or on another electronic device (FIG. 7, dynamic map identifies an incident location of a traffic accident and the locations of responders within the area/perimeter of the incident. As described in more detail below, the dispatcher can use this information to identify traffic slow downs, to provide support to responders en route, and/or to adjust the dispatch based on responder progress [0101]-[0103]).
Regarding claim 15, Pfeffer discloses,
wherein estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location includes comparing a number of ongoing emergencies with available emergency resources (Resource manager 601 also includes information regarding a level of alert for the geographic region, shift information relevant to responders, agencies, and/or equipment, etc. The level of alert can be based on the weather, the number of active incidents, the number of available resources, information received from various agencies regarding potential threats, unusual events occurring in the area that may require support (i.e., parades, sporting events, festivals, etc.), etc. If the level of alert exceeds a predetermined threshold, the dispatcher or task management system can send out requests for additional responders to make themselves available [0077]; the task management system can also determine an expected arrival time of the responder at the incident location. The expected arrival time can be based on the responder's current mode of transportation, the weather, traffic, and/or the ability of the responder disobey traffic laws. The task management system can also estimate times that the responder will pass various locations along his/her route to the incident location [0094]).
Regarding claim 17, Pfeffer discloses,
wherein the step of determining whether at least one facility location of at least one responder facility is known comprises determining a plurality of responder facilities within a predefined vicinity of the emergency location and determining whether a plurality of facility locations of the plurality of responder facilities are known (dispatch engine 175 can identify a geographic area surrounding an incident location from which responders will be requested. Alternatively, the area can be a predetermined range, such as x square kilometers from the incident location. Mapping engine 180, which can be part of a comprehensive geographic information system, can have numerous functions, including providing directions to responders, identifying alternate routes based on traffic or weather, providing aerial photographs, identifying topography, etc [0042]; A process similar to that described in operations 540 through 572 with respect to the responder queue can be used to go through the equipment queue to ensure that adequate equipment is dispatched to the incident. For example, an ambulance may be listed in the equipment queue and the dispatch sent to an ambulance service located closest to the incident location [0100])).
Regarding claim 18, Pfeffer discloses,
wherein estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location comprises estimating at least one of a distance or time of arrival from each of the plurality of responder facilities to the emergency location to provide a plurality of estimated distances or times of arrival (dispatch engine 175 can identify a geographic area surrounding an incident location from which responders will be requested. Alternatively, the area can be a predetermined range, such as x square kilometers from the incident location. Mapping engine 180, which can be part of a comprehensive geographic information system, can have numerous functions, including providing directions to responders, identifying alternate routes based on traffic or weather, providing aerial photographs, identifying topography, etc….. The incident effectiveness can be specific to each incident, and can be based on a plurality of factors, including an amount of time it will take the responder to travel to the incident location. The responder database can include information regarding the responder's mode of transportation [0042]-[0044]; A process similar to that described in operations 540 through 572 with respect to the responder queue can be used to go through the equipment queue to ensure that adequate equipment is dispatched to the incident. For example, an ambulance may be listed in the equipment queue and the dispatch sent to an ambulance service located closest to the incident location [0100]).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 3 and 16 rejected under 35 U.S.C. 103 as being unpatentable over Pfeffer, and further in view of Church et al. (US 6058370, hereinafter “Church”).
Regarding claim 3, Pfeffer discloses everything claimed as applied above (see claim 1), however Pfeffer does not disclose, wherein a time multiplier is computed from the step of comparing a number of ongoing emergencies with available emergency resources and is used to estimate the time of arrival from the at least one facility location to the emergency location.
In the same field of endeavor, Church discloses, wherein a time multiplier is computed from the step of comparing a number of ongoing emergencies with available emergency resources and is used to estimate the time of arrival from the at least one facility location to the emergency location (Data for each week of the historical period is likewise entered into the active calls table. A sum is then computed for each active unit for the historical period [520]; in this sample, there were four calls that were the 6 active call during the historic period; 48 that were the 7th active call; 73 that were the 8th active call; 40 that were the 9th active call; and 3 that were the 10th active call, Col. 9; lines 21-Col. 10; lines 30).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein a time multiplier is computed from the step of comparing a number of ongoing emergencies with available emergency resources and is used to estimate the time of arrival from the at least one facility location to the emergency location, as taught by Church for the purpose of gathering and analyzing emergency service data for the purposes of forecasting future emergency medical service requirements, allocating resources, and generating work schedules (Col. 1; lines 6-9).
Regarding claim 16, Pfeffer discloses everything claimed as applied above (see claim 15), however Pfeffer does not disclose, wherein a time multiplier is computed from the step of comparing a number of ongoing emergencies with available emergency resources and is used to estimate the time of arrival from the at least one facility location to the emergency location.
In the same field of endeavor, Church discloses, wherein a time multiplier is computed from the step of comparing a number of ongoing emergencies with available emergency resources and is used to estimate the time of arrival from the at least one facility location to the emergency location (Data for each week of the historical period is likewise entered into the active calls table. A sum is then computed for each active unit for the historical period [520]; in this sample, there were four calls that were the 6 active call during the historic period; 48 that were the 7th active call; 73 that were the 8th active call; 40 that were the 9th active call; and 3 that were the 10th active call, Col. 9; lines 21-Col. 10; lines 30).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein a time multiplier is computed from the step of comparing a number of ongoing emergencies with available emergency resources and is used to estimate the time of arrival from the at least one facility location to the emergency location, as taught by Church for the purpose of gathering and analyzing emergency service data for the purposes of forecasting future emergency medical service requirements, allocating resources, and generating work schedules (Col. 1; lines 6-9).
Claims 7 and 19 rejected under 35 U.S.C. 103 as being unpatentable over Pfeffer, and further in view of Reich et al. (US 20120196557, hereinafter “Reich”).
Regarding claim 7, Pfeffer discloses everything claimed as applied above (see claim 6), however Pfeffer does not disclose, wherein the plurality of estimated distances or times of arrival are averaged to provide an average estimated distance or time of arrival. In the same field of endeavor, Reich discloses, wherein the plurality of estimated distances or times of arrival are averaged to provide an average estimated distance or time of arrival (an estimated average time to administer care is calculated to be 520 seconds with an assumed standard deviation of .+-.30 seconds. Given a ratio of RED sectors to non-RED sectors, p, a RED sector delta time, dt, and a total number of calls, n, n*p randomly selected calls are handled by RED sectors and the rest are handled by a state highway patrol. For calls handled by RED sectors, the mean first response time=520-dt……. The response time control 510 displays the average amount of time an emergency responder takes to respond to an emergency in the selected sub region. For example, the average response time in Los Angeles may be 520 seconds [0065]-[0069]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein the plurality of estimated distances or times of arrival are averaged to provide an average estimated distance or time of arrival, as taught by Reich for the purpose of effectively communicating information associated with emergency calls communicated to emergency response centers [0007].
Regarding claim 19, Pfeffer discloses everything claimed as applied above (see claim 18), however Pfeffer does not disclose, wherein the plurality of estimated distances or times of arrival are averaged to provide an average estimated distance or time of arrival. In the same field of endeavor, Reich discloses, wherein the plurality of estimated distances or times of arrival are averaged to provide an average estimated distance or time of arrival (an estimated average time to administer care is calculated to be 520 seconds with an assumed standard deviation of .+-.30 seconds. Given a ratio of RED sectors to non-RED sectors, p, a RED sector delta time, dt, and a total number of calls, n, n*p randomly selected calls are handled by RED sectors and the rest are handled by a state highway patrol. For calls handled by RED sectors, the mean first response time=520-dt……. The response time control 510 displays the average amount of time an emergency responder takes to respond to an emergency in the selected sub region. For example, the average response time in Los Angeles may be 520 seconds [0065]-[0069]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein the plurality of estimated distances or times of arrival are averaged to provide an average estimated distance or time of arrival, as taught by Reich for the purpose of effectively communicating information associated with emergency calls communicated to emergency response centers [0007].
Claims 8, 10, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pfeffer, and further in view of Barash et al. (US 20110117878, hereinafter “Barash”).
Regarding claim 8, Pfeffer discloses everything claimed as applied above (see claim 1), however Pfeffer does not disclose, wherein the step of estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location uses a navigation API.
In the same field of endeavor, Barash discloses, wherein the step of estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location uses a navigation API (the dispatch center may provide a latitude and longitude for responder 104A and a latitude and longitude for victim 102, to a navigation system that is publicly available (via a published application programming interface (API)), and a navigation system may respond by providing data for drawing the map overlaid with a thick navigation route line for an optimal path between the two points for the responder 104A [0055]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein the step of estimating at least one of a distance or time of arrival from the at least one facility location to the emergency location uses a navigation API, as taught by Barash for the purpose of providing techniques for providing response to emergency situations, such as traffic accidents, cardiac arrest, or other medical emergencies [0002].
Regarding claim 10, Pfeffer discloses everything claimed as applied above (see claim 1), however Pfeffer does not disclose, wherein both a distance and a time of arrival are estimated from the at least one facility location to the emergency location.
In the same field of endeavor, Barash discloses, wherein both a distance and a time of arrival are estimated from the at least one facility location to the emergency location (the dispatch center may provide a latitude and longitude for responder 104A and a latitude and longitude for victim 102, to a navigation system that is publicly available (via a published application programming interface (API)), and a navigation system may respond by providing data for drawing the map overlaid with a thick navigation route line for an optimal path between the two points for the responder 104A [0055]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein both a distance and a time of arrival are estimated from the at least one facility location to the emergency location, as taught by Barash for the purpose of providing techniques for providing response to emergency situations, such as traffic accidents, cardiac arrest, or other medical emergencies [0002].
Regarding claim 13, Pfeffer discloses everything claimed as applied above (see claim 1), however Pfeffer does not disclose, responsive to determining whether a current location of one or more responders is known, using a navigation API to estimate at least one of a distance or time of arrival of the one or more responders to the emergency location.
In the same field of endeavor, Barash discloses, responsive to determining whether a current location of one or more responders is known, using a navigation API to estimate at least one of a distance or time of arrival of the one or more responders to the emergency location (the dispatch center may provide a latitude and longitude for responder 104A and a latitude and longitude for victim 102, to a navigation system that is publicly available (via a published application programming interface (API)), and a navigation system may respond by providing data for drawing the map overlaid with a thick navigation route line for an optimal path between the two points for the responder 104A [0055]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing responsive to determining whether a current location of one or more responders is known, using a navigation API to estimate at least one of a distance or time of arrival of the one or more responders to the emergency location, as taught by Barash for the purpose of providing techniques for providing response to emergency situations, such as traffic accidents, cardiac arrest, or other medical emergencies [0002].
Regarding claim 20, Pfeffer discloses everything claimed as applied above (see claim 18), however Pfeffer does not disclose, wherein estimating at least one of a distance or time of arrival from each of the plurality of responder facilities to the emergency location to provide a plurality of estimated distances or times of arrival uses a navigation API.
In the same field of endeavor, Barash discloses, wherein estimating at least one of a distance or time of arrival from each of the plurality of responder facilities to the emergency location to provide a plurality of estimated distances or times of arrival uses a navigation API (the dispatch center may provide a latitude and longitude for responder 104A and a latitude and longitude for victim 102, to a navigation system that is publicly available (via a published application programming interface (API)), and a navigation system may respond by providing data for drawing the map overlaid with a thick navigation route line for an optimal path between the two points for the responder 104A [0055]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein estimating at least one of a distance or time of arrival from each of the plurality of responder facilities to the emergency location to provide a plurality of estimated distances or times of arrival uses a navigation API, as taught by Barash for the purpose of providing techniques for providing response to emergency situations, such as traffic accidents, cardiac arrest, or other medical emergencies [0002].
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Pfeffer, and further in view of Friesen (US 20150289122, hereinafter “Friesen”).
Regarding claim 9, Pfeffer discloses everything claimed as applied above (see claim 1), however Pfeffer does not disclose, wherein the at least one of an estimated distance or time of arrival from the at least one facility location to the emergency location is displayed on the user electronic device.
In the same field of endeavor, Friesen discloses, wherein the at least one of an estimated distance or time of arrival from the at least one facility location to the emergency location is displayed on the user electronic device (the system can request the location of a Reporting Party requesting emergency assistance, to which the Reporting Party can respond with location information, for example and without limitation, via a text message, voice message, smartphone application, and/or GPS device. Such a Location Request can be made, periodically and/or after receiving a request for assistance, for example to update the system with new location coordinates….. The system can utilize time estimates manually provided by the First Responder and/or calculated by the system to determine which First Responders are most suitable to respond to the incident and which First Responders are not needed to respond. For example, a First Responder ten minutes away from the scene of an incident can be selected, while a First Responder twenty minutes away can be denied. The system can also consider and provide a suitable type or number of transportation options [0027]- [0032]).
Therefore, it would have been obvious to one of ordinary skill in art before the effective filing date of the claimed invention to modify Pfeffer by specifically providing wherein the at least one of an estimated distance or time of arrival from the at least one facility location to the emergency location is displayed on the user electronic device, as taught by Friesen for the purpose of providing technique includes receiving at least one request for emergency assistance, alerting registered responders in a geographic area corresponding to an emergency site of said request for emergency assistance [0007].
Prior Art of the Record:
The prior art made of record not relied upon and considered pertinent to
Applicant’s disclosure:
US 11594088: A method of access control for emergency responders according to one embodiment includes transmitting, by an access control server, an access credential to an emergency responder server over a first network, transmitting, by the emergency responder server, the access credential to an emergency responder mobile device over a second network different from the first network.
US 11528771: This document relates to systems and techniques for providing response to emergency situations, such as traffic accidents, cardiac arrest, or other medical emergencies. The systems and techniques include systems and techniques for identifying and accessing emergency response equipment during a medical emergency.
US 20180330600: An emergency communication system comprises at least two distributed servers. Each of the servers is an independently functioning device configured to operate cooperatively with another server, store personal data of users, duplicate data, and so forth. The servers are connected to a dispatch center, user devices of users, and personal devices of responders through two or more communications networks.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GOLAM SOROWAR whose telephone number is (571)270-3761. The examiner can normally be reached Mon-Fri: 8:30AM-5PM.
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, Charles Appiah can be reached at (571) 272-7904. 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.
/GOLAM SOROWAR/Primary Examiner, Art Unit 2641
Prosecution Insights