Prosecution Insights
Last updated: October 02, 2026
Application No. 18/759,647

RAILROAD CROSSING BLOCKAGE DETECTION AND NOTIFICATION SYSTEM

Non-Final OA §103
Filed
Jun 28, 2024
Priority
Oct 10, 2023 — provisional 63/543,453
Examiner
DWYER, MATTHEW JAMES
Art Unit
Tech Center
Assignee
Rapidsos Inc.
OA Round
1 (Non-Final)
100%
Grant Probability
Favorable
1-2
OA Rounds
4m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 100% — above average
100%
Career Allowance Rate
1 granted / 1 resolved
+40.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 7m
Avg Prosecution
28 currently pending
Career history
35
Total Applications
across all art units

Statute-Specific Performance

§103
68.2%
+28.2% vs TC avg
§102
23.4%
-16.6% vs TC avg
§112
8.4%
-31.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 1 resolved cases

Office Action

§103
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 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. 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. Claims 1, 2, 4-7, 9, 11-14, 16-18, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Hilleary (US 2024/0157988 A1, hereinafter Hilleary) in view of Liu (US 2026/0062039 A1, hereinafter Liu). Regarding claim 1, Hilleary teaches an emergency management system ([0081] describes "trusted predictive railroad crossing notification system 300 which advantageously determines train ETA and blocked crossing duration estimates," i.e. a train crossing model. The train crossing model (predictive railroad crossing notification system 300, depicted in FIGS. 1-3) is capable of providing emergency management, [0068] describes "further facilitates an optimization of emergency dispatch and routing". Additionally, the emergency management system is specifically for "proactive management of train arrival and blocked crossing probabilities," see [0063]) comprising: a cloud server (FIG. 3 depicts predictive railroad notification system 300 connected to database 326, i.e. a cloud server, see [0101]), comprising a network component and at least one processor, operatively coupled to the network component ([0096] describes "the predictive railroad crossing notification system 300 is configured as one or more computer servers including a processor 302 and a memory 304," i.e. comprising a processor. Additionally, [0097] describes "the TSC Interface 306 may be realized through wired and wireless connections, including but not limited to radio frequency signal transmission and cellular signal transmission of data and information, and networked computer connections including but not limited to the Internet," i.e. a network component. See FIG. 3, TSC interface 306 and processor 302), the at least one processor, operative to: receive sensor data from infrastructure sensors that are positioned proximate to a railroad crossing ([0095] "the train sensing systems 104a, 104b, 104c, 104d could provide sufficient data upon which the predictive railroad crossing notification system 300," i.e. receive sensor data directly from the train, which may be at the railroad crossing. Additionally, [0052] describes the use of a "sensor system (either a railroad-based detection system or third party detection system) at the crossings," i.e. the system 300 may use sensors from trains or from the crossing area), wherein the railroad crossing is an intersection between a road and a railroad ([0052] describes a situation wherein the crossing would be an intersection between a road and a railroad); determine a likelihood of a blockage of the railroad at the railroad crossing based on the sensor data- ([0105] "the prediction components 318 also determine crossing blockage duration values based on train speed and train length data and information from the train control system 200," i.e. determining blockage information of the railroad at the crossing based on data from the train control system 200, which includes sensor data, see FIG. 2); and notify an emergency communications center (ECC) of the likelihood of the blockage of the railroad at the railroad crossing (FIG. 14 depicts the Predictive Railroad Crossing Notification System 300 notifying an emergency vehicle dispatch system, which may include "vehicle dispatch systems 700 such as emergency vehicle dispatch centers," see [0125], i.e. notifying an ECC). Hilleary is not relied on for the claim language receive emergency call data from mobile devices that initiated 911 calls proximate to the railroad crossing; -and the emergency call data. However, Liu teaches [abstract] a method to enable automated intelligent railway monitoring using railway image data, wherein a railway object recognition model is used to identify objects within the image frames and a railway condition is determined based on the object. Liu also teaches receive emergency call data from mobile devices that initiated 911 calls proximate to the railroad crossing; -and the emergency call data (Figure 21 and 22 depict user devices 2102-2104 and 2202n that are capable of making emergency phone calls to report an emergency of a train, see [0249]). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 2, Hilleary is not relied on for the claim language the infrastructure sensors include at least one of: cameras, pressure sensors, power line sensors, water pressure sensors, moisture detection sensors, or proximity sensors. However, Liu teaches as such (the infrastructure sensors include cameras as depicted in FIG. 1, wherein the sensors act as inputs to perform predictive monitoring and assessment of railway conditions, see FIG. 1 and [0046]). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 4, Hilleary teaches the at least one processor is further operative to: receive sensor data from infrastructure sensors that are positioned proximate to a railroad crossing, within a radius of up to 500 meters from a center of the railroad crossing ([0043] describes "detection of trains utilizing third party supplied radar and infrared detectors, and communication of impending roadway blockages to a crossing ahead of those detection points to signage located at the crossings for the benefit of motorists. The crossings outfitted with radar and infrared detectors or sensors may or may not include active warning systems of the railroad operator," i.e. using infrastructure sensors positioned proximate to a railroad crossing within a radius is a known and well defined technique in the art dealing with train safety and detection). Regarding claim 5, Hilleary teaches the at least one processor is further operative to: determine a likelihood of a blockage of the railroad at the railroad crossing- ([0070] describes determining a blockage of the railroad at the railroad crossing). Hilleary is not relied on for the claim language -based on the sensor data detecting a vehicle positioned on or between tracks of the railroad. However, Liu teaches as such ([0226] "FIG. 11 and FIG. 12 show detected trespassers in a right of way and a grade crossing displayed on the web, including a right-of-way trespassing example in FIG. 11 and a grade crossing trespassing in FIG. 12," i.e. FIG. 12 depicts the detection of a vehicle positioned on the railroad tracks). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 6, Hilleary teaches the at least one processor is further operative to: determine a likelihood of a blockage of the railroad at the railroad crossing- ([0070] describes determining a blockage of the railroad at the railroad crossing). Hilleary is not relied on for the claim language -based on the sensor data detecting a vehicle positioned within two feet of tracks of the railroad. However, Liu teaches as such (FIG. 12 depicts a vehicle positioned on or near, on or near read as within two feet, the tracks of the railroad, see [0226]). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 7, Hilleary teaches the at least one processor is further operative to: provide a data interface from the cloud server to an ECC network entity; and send an infrastructure message to the ECC to initiate train collision avoidance protocols, wherein the infrastructure message includes the likelihood of the blockage of the railroad at the railroad intersection ([0144] describes "the controller including the microprocessor 524 is responsive to the data outputs of the predictive railroad crossing notification system 300 or to a communication from a crossing system 450 that has been supplied the data outputs of the predictive railroad crossing notification system 330," wherein the notification system may also be the Emergency Vehicle Dispatch System as depicted in FIG. 14, i.e. providing the generated likelihood of the blockage of the railroad at the railroad intersection to the ECC). Regarding claim 9, Hilleary teaches the at least one processor is further operative to: initially detect a potential blockage of the railroad- and request the sensor data from some of the infrastructure sensors ([0095] "the train sensing systems 104a, 104b, 104c, 104d could provide sufficient data upon which the predictive railroad crossing notification system 300," i.e. receive sensor data directly from the train, which may be at the railroad crossing. Additionally, [0052] describes the use a "sensor system (either a railroad-based detection system or third party detection system) at the crossings," i.e. the system 300 may use/request sensors from trains or from the crossing area); Hilleary is not relied on for the claim language -based on the emergency call data; verify the potential blockage of the railroad based on the sensor data; and update the likelihood of the blockage of the railroad. However, Liu teaches -based on the emergency call data (Figure 21 and 22 depict user devices 2102-2104 and 2202n that are capable of making emergency phone calls to report an emergency of a train, see [0249]); verify the potential blockage of the railroad based on the sensor data; and update the likelihood of the blockage of the railroad ([0235] "the engineering module may perform automated cross-check (train detection, signal detection and gate detection)," i.e. verifying the potential blockage information is correct. Additionally, [0135] describes information can be "updated periodically as needed"). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 11, Hilleary teaches the at least one processor is further operative to: apply the sensor data- -to a machine learning model to determine the likelihood of the blockage of the railroad (FIG. 5 depicts sensor data from the train (102) and from the proximity of the crossing (104) being applied as inputs to the Predictive Railroad Crossing Notification System 300. Wherein the Predictive Railroad Crossing Notification System 300 includes machine learning components 324 as depicted in FIG. 3 and [0098]. Wherein machine learning components 324 assist in [0063] "proactive management of train arrival and blocked crossing probabilities"). Hilleary is not relied on for the claim language -and the emergency call data-. However, Liu teaches as such (Figure 21 and 22 depict user devices 2102-2104 and 2202n that are capable of making emergency phone calls to report an emergency of a train, see [0249]). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 12, Hilleary teaches the at least one processor is further operative to: train the machine learning model to determine the likelihood of the blockage of the railroad with historical data for train collisions ([0113] "Machine learning components 324 analyze estimates produced by the system 300 and improves ETA and blocked crossing duration estimates even further. For example, current estimates may be compared to prior estimates, and patterns may be deduced that may desirably lead to adjustments in the estimates generated at each iteration," i.e. the machine learning model 324, see FIG. 3, is trained on historical data for probability corrections in association with train blockage and train collisions). Regarding claim 13, Hilleary is not relied on for the claim language the historical data for the train collisions comprises historical emergency call data patterns initiated in proximity to railroad crossings that had some of the train collisions. However, Liu teaches as such ([0156] - [0157] the historical data may include "installation and maintenance history of various railway infrastructure and infrastructure components" such as the ability to have "each defect entry or record may include the defect, defect type, location, time, installation history, maintenance history, etc. to record defect attributes." Furthermore, [0165] describes "the decision support layer 150 may include a recommendation engine 150 that uses a railway condition prediction model to predict a future railway condition based on current and/or historical railway conditions" and "the predictions are based on collected historical data and statistical and/or machine learning models to predict an occurrence, likelihood of occurrence, duration or any combination thereof of a future railway condition," i.e. the method is capable of receiving a plurality of historical information about railway conditions, i.e. historical train collisions. Wherein said historical events may include phone calls related to the historical train collision, as described in claim 1 and [0249]). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 14, Hilleary is not relied on for the claim language the historical data for the train collisions comprises historical sensor data for some of the infrastructure sensors. However, Liu teaches as such ([0088] describes "an intelligent railway analytics platform 100 may include hardware and/or software for receiving, processing and analyzing real-time and historical imagery from a network of fixed location and vehicle mounted image sensing devices (e.g., cameras (RGB color camera), thermal camera, infrared camera, LIDAR, among others or any combination thereof) to automatically monitor and assess railway conditions," i.e. historical data of train collisions from sensor data). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 16, Hilleary is not relied on for the claim language the at least one processor is further operative to: determine that the likelihood of the blockage exceeds a pre-determined threshold; and send a control signal to decelerate a train from an initial speed, wherein the train is in-bound to the railroad crossing. However, Liu teaches the at least one processor is further operative to: determine that the likelihood of the blockage exceeds a pre-determined threshold ([0216] describes the use of a threshold in association with determining a positive signal detection of a potential collision hazard, i.e. exceeding an established threshold to send a command signal); and send a control signal to decelerate a train from an initial speed, wherein the train is in-bound to the railroad crossing ([0183] "the optimal collision avoidance action can be taken (e.g. early warning, slow down or stop) to ensure safety," i.e. capabilities to perform a control signal to decelerate a train). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 17, Hilleary is not relied on for the claim language the at least one processor is further operative to: send the control signal is to decelerate a train without stopping the train, to reduce a quantity of time used to return the train to the initial speed. However, Liu teaches as such (as described in claim 16, the train may be instructed to only "slow down," see [0183]). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 18, Hilleary is not relied on for the claim language the at least one processor is further operative to: identify a stoppage of a train at the railroad crossing; search an infrastructure database for a length of the train; identify additional railroad crossings that are potentially blocked by the stoppage of the train; and provide a blockage notification for the railroad crossing and the additional railroad crossings to at least one of the ECC or a navigation software server. However, Liu teaches the at least one processor is further operative to: identify a stoppage of a train at the railroad crossing; search an infrastructure database for a length of the train ([0148] describes "the detection of the train by the fixed location image processing model engine 122 (also capable of determining a stopped object/train, see [0238]) may also include detection of a train type and/or train length. The train type and/or the train length may be appended to the train arrival delay entry or record to facilitate generating train arrival delay metrics and statistics according to train characteristics," i.e. identifying a stopped train and train length); identify additional railroad crossings that are potentially blocked by the stoppage of the train ([0228] describes FIGS. 13 and 14 "provide time-series heatmaps of trespass occurrence and predictions of future trespasses using current data," trespasses read as additional railroad crossings potential blockages, i.e. the ability to detect multiple potentially blocked crossings simultaneously); and provide a blockage notification for the railroad crossing and the additional railroad crossings to at least one of the ECC or a navigation software server ([0164] "computing device 160 may also or alternatively be associated with third-party entities, such as, e.g., rail agencies, governmental departments of transportation, emergency responders, among others," i.e. the ability to forward predictions to ECC or other institutions). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 23, Hilleary teaches a method comprising: receiving sensor data from infrastructure sensors that are positioned within a pre-determined radius of a first railroad crossing, ([0095] "the train sensing systems 104a, 104b, 104c, 104d could provide sufficient data upon which the predictive railroad crossing notification system 300," i.e. receive sensor data directly from the train, which may be at the railroad crossing. Additionally, [0052] describes the use a "sensor system (either a railroad-based detection system or third party detection system) at the crossings," i.e. the system 300 may use sensors from trains or from the crossing area. Furthermore, [0043] describes "detection of trains utilizing third party supplied radar and infrared detectors, and communication of impending roadway blockages to a crossing ahead of those detection points to signage located at the crossings for the benefit of motorists. The crossings outfitted with radar and infrared detectors or sensors may or may not include active warning systems of the railroad operator," i.e. using infrastructure sensors positioned proximate to a railroad crossing within a radius is a known and well defined technique in the art dealing with train safety and detection) the first railroad crossing being an intersection between a road and a railroad ([0052] describes a situation wherein the crossing would be an intersection between a road and a railroad). Hilleary is not relied on for the claim language identifying a stoppage of a train at the first railroad crossing based on the sensor data; querying an infrastructure database for a length of the train; identifying additional railroad crossings that are potentially blocked by the stoppage of the train; and providing a blockage notification for the first railroad crossing and the additional railroad crossings to at least one of an emergency communications center (ECC) or a navigation software server. However, Liu teaches identifying a stoppage of a train at the first railroad crossing based on the sensor data; querying an infrastructure database for a length of the train ([0148] describes "the detection of the train by the fixed location image processing model engine 122 (also capable of determining a stopped object/train, see [0238]) may also include detection of a train type and/or train length. The train type and/or the train length may be appended to the train arrival delay entry or record to facilitate generating train arrival delay metrics and statistics according to train characteristics," i.e. identifying a stopped train and train length); identifying additional railroad crossings that are potentially blocked by the stoppage of the train ([0228] describes FIGS. 13 and 14 "provide time-series heatmaps of trespass occurrence and predictions of future trespasses using current data," trespasses read as additional railroad crossings potential blockages, i.e. the ability to detect multiple potentially blocked crossings simultaneously); and providing a blockage notification for the first railroad crossing and the additional railroad crossings to at least one of an emergency communications center (ECC) or a navigation software server ([0164] "computing device 160 may also or alternatively be associated with third-party entities, such as, e.g., rail agencies, governmental departments of transportation, emergency responders, among others," i.e. the ability to forward predictions to ECC or other institutions). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Claims 3, 8, 10, 15, 19-22, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Hilleary (US 2024/0157988 A1, hereinafter Hilleary) and Liu (US 2026/0062039 A1, hereinafter Liu) as applied in claims above, and further in view of Pellegrini et al. (US 2022/0051548 A1, hereinafter Pellegrini). Regarding claim 3, the combination of Hilleary and Liu is not relied on for the claim language the at least one processor is further operative to: receive emergency call data location data and timestamp data for each of the mobile devices, wherein the emergency call data excludes audio voice data. However, Pellegrini teaches [abstract] a method for receiving emergency alarms, and [0038] training a ML model to determine the verification of said alarms. Pellegrini also teaches the at least one processor is further operative to: receive emergency call data location data and timestamp data for each of the mobile devices (FIG. 13 depicts each emergency call has a corresponding timestamp and associated location of the device. This data is used for: "machine learning algorithm is fed appropriate amounts of emergency data from alarms, emergency calls and sensors to form a training procedure that is used to train the alarm signal processor 200," i.e. using timestamps and locations from an emergency call to train a prediction model), wherein the emergency call data excludes audio voice data (the gathered information from each emergency call depicted in FIG. 13 would not include the audio of the voice data when received by the user). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. Regarding claim 8, Hilleary teaches the at least one processor is further operative to: provide an instance of a cloud application to the ECC- (FIG. 14 depicts the Predictive Railroad Crossing Notification System 300 providing the results for a crossing to an Emergency Vehicle Dispatch System 720, Emergency Vehicle Dispatch System 720 read as ECC). The combination of Hilleary and Liu is not relied on for the claim language -via an emergency data manager portal; and notify an ECC, wherein the ECC is a network operations center (NOC) or a public safety answering point (PSAP) that includes an infrastructure management application or an emergency data manager portal. However, Pellegrini teaches -via an emergency data manager portal ([0073] describes the emergency system is provided to an ECC user via "display 141 and emergency data manager portal 144" also see FIGS. 11-21, which depict the data manager portal); and notify an ECC, wherein the ECC is a network operations center (NOC) or a public safety answering point (PSAP) that includes an infrastructure management application or an emergency data manager portal ([0066] describes "the various emergency networks 170 may include various public safety answering points (PSAPs) which may answer emergency calls and accordingly dispatch police, fire departments and ambulances. Each emergency network such as, but not limited to a PSAP, may include an emergency dispatch center and employ a computer aided dispatch (CAD) system" i.e. notifying a PSAP that includes an emergency data manager portal). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. Regarding claim 10, Hilleary teaches and set likelihood of the blockage to the high level in response to verification of the potential blockage based on the infrastructure sensor data (as described in claim 9, the [0063] "proactive management of train arrival and blocked crossing probabilities" may be verified and updated, see [0235] and [0135]). The combination of Hilleary and Liu is not relied on for the claim language the at least one processor is further operative to: quantize the likelihood of the blockage into a low level, a medium level, and a high level; However, Pellegrini teaches as such ([0052] describes the emergency event may be placed at higher or lower priority levels. FIG. 14 depicts this priority level as a score). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. Regarding claim 15, Hilleary teaches the at least one processor is further operative to: quantize a numeric representation of the likelihood of the blockage of the railroad- ([0063] the invention is responsible for "train arrival and blocked crossing probabilities," i.e. quantizing prediction values of the Predictive Railroad Crossing Notification System 300 into probabilities, i.e. quantize a numeric representation of the likelihood of the blockage of the railroad). The combination of Hilleary and Liu is not relied on for the claim language -into two or more risk categories. However, Pellegrini teaches as such ([0052] describes the emergency event may be placed at higher or lower priority levels. FIG. 14 depicts this priority level as a score). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. Regarding claim 19, Hilleary teaches a method comprising: -from a railroad crossing, the railroad crossing being an intersection between a road and a railroad (the emergency management system is specifically for "proactive management of train arrival and blocked crossing probabilities," see [0063]. Wherein the crossing is an intersection between a road and a railroad as described by the situation described in [0052]); and transmitting the blockage data to a user interface associated with the ECC ([0144] describes "the controller including the microprocessor 524 is responsive to the data outputs of the predictive railroad crossing notification system 300 or to a communication from a crossing system 450 that has been supplied the data outputs of the predictive railroad crossing notification system 330," wherein the notification system may also be the Emergency Vehicle Dispatch System as depicted in FIG. 14, i.e. providing the likelihood of the blockage of the railroad at the railroad intersection to the ECC). Hilleary is not relied on for the claim language generating blockage data that is representative of a likelihood of a blockage of the railroad at the railroad crossing based on the emergency call data. However, Liu teaches as such (Figure 21 and 22 depict user devices 2102-2104 and 2202n that are capable of making emergency phone calls to report an emergency of a train, see [0249], which may be for predicting/generation data of the railroad crossing scenario, see FIG. 9). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. The combination of Hilleary and Liu is not relied on for the claim language receiving emergency call data from mobile devices that initiated 911 calls within a pre-determined radius and querying a geographic boundary database for geographic boundary data to identify an emergency communications center (ECC) that is associated with the railroad crossing, the geographic boundary data defining a coverage area for the ECC. However, Pellegrini teaches receiving emergency call data from mobile devices that initiated 911 calls within a pre-determined radius (FIG. 13 depicts receiving emergency call data from mobile devices within a radius of an incident) and querying a geographic boundary database for geographic boundary data to identify an emergency communications center (ECC) that is associated with the railroad crossing, the geographic boundary data defining a coverage area for the ECC ([0065] describes "the emergency data manager 100 is operative to determine the authorized emergency network using a geofence database 101 which includes boundary information for all of the emergency networks 170 and also for national or regional emergency networks 180," and [0102] describes "stores jurisdictional boundary data for various emergency networks 170 as well as for the national or regional emergency networks," i.e. the system is capable of determining boundaries for separate ECC coverage areas and storing them in a database. Furthermore, a geographic boundary map may be queried around a specific emergency event (which could be a railroad crossing emergency) as depicted in FIG. 13). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. Regarding claim 20, Hilleary teaches -generating the blockage data- and wherein output of the machine learning model includes the blockage data (FIG. 5 depicts the Predictive Railroad Crossing Notification System 300 (which includes a ML model 324, see FIG. 3) outputting the generated crossing blockage data). The combination of Hilleary and Liu is not relied on for the claim language the emergency call data include location data and timestamp data for the mobile devices during the 911 calls, wherein generating the blockage data includes applying the emergency call data to a machine learning model, wherein output of the machine learning model includes the blockage data. However, Pellegrini teaches the emergency call data include location data and timestamp data for the mobile devices during the 911 calls (FIG. 13 depicts each emergency call has a corresponding timestamp and associated location of the device. This data is used for: "machine learning algorithm is fed appropriate amounts of emergency data from alarms, emergency calls and sensors to form a training procedure that is used to train the alarm signal processor 200," i.e. using timestamps and locations from an emergency call to train a prediction model), wherein generating the blockage data includes applying the emergency call data to a machine learning model, wherein output of the machine learning model includes the blockage data ([0245] see FIG. 30, "in operation block 3015 the result is collected as machine learning training data so that the machine learning algorithm…" i.e. information regarding emergency call data is provided to the machine learning model, further described in [0223] - [0226]). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. Regarding claim 21, Hilleary is not relied on for the claim language query at least one infrastructure database for sensor data from infrastructure sensors that are positioned within the pre-determined radius of the railroad crossing; and updating the likelihood of the blockage of the railroad based on the sensor data. However, Liu teaches as such ([0135] describes information can be "updated periodically as needed," which may be based on "features of each image" or recording , i.e. the method of FIG. 1 is able to be updated based on new information such as infrastructure sensors, wherein said infrastructure sensors may be placed within a radius of the railroad crossing, as explained in [0043] and claim 4). 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 Hilleary to include the use of historical and current emergency calls and camera outputs to be used as inputs for the machine learning algorithm to aid in determining a likelihood of a blockage of the railroad and in making safety decisions regarding the train(s), as taught by Liu, in order to [0073] reduce the cost of grade crossing delays and accidents, while offering a greater accuracy and flexibility, and therefore [0004] improving transportation safety, operational efficiency, resiliency and sustainability. Regarding claim 22, the claimed limitations of claim are rejected as the same reasons as set forth in claim 2. Regarding claim 24, Hilleary teaches wherein the navigation software server is operable to provide mobile devices with traffic updates and map-based navigation services ([0133] describes "navigation system 620 is shown in FIG. 9 as a centralized navigation system 600 for the system 100," and "the system 620 may be a data centric system operable on demand by system users of apps or subscription services. Apple Maps, Google maps and Sirius navigation systems are popular systems of this type," see [0136]. Navigation system 620 may be used to aid in "manage blocked crossing delays via enhanced notifications that, in turn, facilitate route selection and dispatching options," see [0046]). The combination of Hilleary and Liu is not relied on for the claim language the ECC is a network operations center (NOC) or a public safety answering point (PSAP). However, Pellegrini teaches as such ([0066] describes "the various emergency networks 170 may include various public safety answering points (PSAPs) which may answer emergency calls and accordingly dispatch police, fire departments and ambulances. Each emergency network such as, but not limited to a PSAP, may include an emergency dispatch center and employ a computer aided dispatch (CAD) system" i.e. notifying a PSAP that includes an emergency data manager portal). 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 combination of Hilleary and Liu to include the ability to receive emergency call data with timestamps and location information, the ECC to be a PSAP, a manager portal, give priority/quantized risk levels, and querying a geographic boundary around an emergency, as taught by Pellegrini, in order to [0040] provide a graphical user interface for managing an emergency, [0116] provide emergency data pertaining to the emergency, [0132] allow users the ability to access location data, user data, emergency data or sensor data, [0135] decrease emergency response time, and therefore improve the overall safety management of emergencies. References Cited Hilleary, Thomas N. (2024). Predictive railroad crossing safety notification and traffic control system and methods (US 2024/0157988 A1). Filed 2022-11-11. Liu, Xiang (2026). Systems and methods for machine learning enhanced railway condition monitoring, assessment and prediction (US 2026/0062039 A1). Filed 2025-11-11. (Continuity 05/19/2021). Pellegrini, Riccardo et al. (2022). Apparatus, systems and methods for providing alarm and sensor data to emergency networks (US 2022/0051548 A1). Filed 2021-08-17. (Continuity 08/17/2020). Other Pertinent References The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Forrest, Paul et al. (2010). Diagnostic system and method for monitoring a rail system (US 2010/0204857 A1). Filed 2007-09-18. Discloses a safety method for monitoring rail infrastructure and/or rail vehicles. (abstract) Hania, Shahar et al. (2020). System and method for object and obstacle detection and classification in collision avoidance of railway applications (US 2020/0307661 A1). Filed 2017-10-19. Discloses a system for detection and identification of objects and obstacles near, between or on railway comprise several forward-looking imagers adapted to cover each different range forward and preferably to be sensitive each to different wavelength of radiation, including visible light, LWIR, and SWIR. (abstract) Zhang, Qiang et al. (2022). Anti-collision method and apparatus for trains in cooperative formation (US 2022/0388555 A1). Filed 2020-01-22. Discloses an anti-collision method and apparatus for trains in a cooperative formation. (abstract) Sema, Albi (2024). Self-learning warning system for rail vehicles (US 2024/0043053 A1). Filed 2021-12-20. Discloses a method for detecting obstacles for a rail vehicle. (abstract) Plant, Derek L. (2017). Railroad block/grade crossing warning system (US 2017/0291620 A1). Filed 2017-04-12. Discloses a train safety system for railroad crossing. (abstract) Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J DWYER whose telephone number is (571)272-5121. The examiner can normally be reached M-F 6 a.m. - 3 p.m. EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yuwen Pan can be reached at (571) 272-7855. 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. /MATTHEW JAMES DWYER/Examiner, Art Unit 2649 /GEORGE ENG/Supervisory Patent Examiner, Art Unit 2699
Read full office action

Prosecution Timeline

Jun 28, 2024
Application Filed
Aug 25, 2026
Non-Final Rejection mailed — §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
100%
Grant Probability
99%
With Interview (+0.0%)
2y 7m (~4m remaining)
Median Time to Grant
Low
PTA Risk
Based on 1 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month