Prosecution Insights
Last updated: October 25, 2026
Application No. 18/100,986

SAFETY NOTIFICATIONS

Non-Final OA §103
Filed
Jan 24, 2023
Priority
May 25, 2021 — provisional 63/192,979 +2 more
Examiner
OUELLETTE, JONATHAN P
Art Unit
3629
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Early Warning Services LLC
OA Round
5 (Non-Final)
66%
Grant Probability
Favorable
5-6
OA Rounds
0m
Est. Remaining
96%
With Interview

Examiner Intelligence

Grants 66% — above average
66%
Career Allowance Rate
773 granted / 1165 resolved
+14.4% vs TC avg
Strong +30% interview lift
Without
With
+29.5%
Interview Lift
resolved cases with interview
Typical timeline
3y 8m
Avg Prosecution
40 currently pending
Career history
1215
Total Applications
across all art units

Statute-Specific Performance

§101
29.2%
-10.8% vs TC avg
§103
19.0%
-21.0% vs TC avg
§102
27.3%
-12.7% vs TC avg
§112
10.6%
-29.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 1165 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 . Request for Continued Examination A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9/11/2026 has been entered. Status of Claims Claims 9-10, 18, 21-22 have been cancelled, and Claims 24-25 has been added as new; therefore, Claims 1-8, 11-17, 19-20, and 23-25 are currently pending in application 18/100,986. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-8, 12-17, 19-20, 23, and 25 are rejected under 35 U.S.C. 103(a) as being unpatentable over deCharms (US 2014/0368601 A1) in view of White et al. (US 10,362,471 B1). As per independent Claims 1, 12, and 20, deCharms discloses a computer-implemented method/ system/ programmed apparatus of transmitting a safety notification using one or more processors (See at least Figs.1-2, 7-8; Para 0260; Claims 1, 13, and 19), comprising: instructing, by a computer system to a first electronic device, to display on an interface of the first electronic device setting options to display the safety notification; determining, by the computer system, a user input on the interface selecting a notification option (See at least Figs. 7, 18A-18B, User system/method registration; Para 0150 and Para 0232); receiving, by the computer system, session information associated with a data transfer session of the first electronic device transferring data with a second electronic device; determining, by the computer system, based at least in part on the session information, a location of the first electronic device associated with a user when the data was transferred and a first time when the data was transferred (See at least Para 0005, “… the verification features can include one or more of: a timestamp, a digital watermark, and location information (AE) …”; Para 0280, “In one example, a user (calling user) can send a message including a URL link through a messaging platform (email, SMS, Facebook, others) to a responder. This URL link can contain information specifying the sender, or the sender and responder, or the sender, responder. The URL link can also optionally include additional information, including information about the kind of communication being requested, the nature of the situation or topic of communication, the means of communicating, the locations of one or both users, encryption information (for example including a public key), or other information.”); receiving, by the computer system, event data including an event location of an event, a severity of the event, and a second time of when the event occurred (See at least Para 0005, Para 0284, “Risk levels indicating the level of severity of the events can be provided with the news alerts. For example, news of a tornado around the current location of a user can be accompanied by a "high" risk level indicating that the event (tornado) posed a great risk to the health and well-being of people nearby. In another example, news of a thunderstorm with the chance to cause minor flooding can be accompanied with a "low" risk level indicating that the event (thunderstorm) posed a low risk to the health and well-being of people nearby. Risk levels can be determined manually and/or automatically, such as through keyword and/or phrase analysis, and/or natural language processing to match news alerts to predetermined event types each with one or more associated risk levels.”); determining, by the computer system, a threshold distance from the event location based at least in part on at least one of the severity of the event (Threat Level) or the notification option (See at least Para 0260, “Additional and/or alternative data sources can be used to provide geotargeted alerts to users who are located within one or more relevant geographic locations. For example, data sources providing information about emergencies (e.g., national emergency monitoring system) and/or weather-related events (e.g., weather/ meteorological systems) can be accessed or can push information to this system and, when an event with at least a threshold predicted or occurring level of severity is identified, users that are located inside or within a selected distance from the affected area can receive an alert (e.g., message, recorded message, push notification) to inform them of the event, and people whom they have designated (for example their friends) can also receive a notification.”); determining, by the computer system, whether the first electronic device satisfies the distance from the event location, and whether a time period between the first time and the second time satisfies a period of time; and where the location satisfies the distance and the period of time, transmitting, by the computer system to the first electronic device, the safety notification regarding the event (See at least Para 0194, “The central computer system 802 receives the incident report (814). The central computer server system 802 can provide security alerts to other users based on the incident report, as indicated by steps 815a-c. For example, the computer server system 802 can identify other users to whom the incident may be relevant and/or important (815a), such as users who are currently or are likely in the future (e.g., within a threshold period of time) to be located near where the incident occurred …”, The server operates by cross-referencing real-time/future location data against the geographical coordinates of an incident to broadcast relevant notifications). While deCharms does disclose determining, by the computer system, whether the first electronic device satisfies the distance from the event location, and whether a time period between the first time and the second time satisfies a period of time; and where the location satisfies the distance and the period of time, transmitting, by the computer system to the first electronic device, the safety notification regarding the event (See at least Para 0194, See rejection above); deCharms fails to expressly disclose determining, by the computer system, whether the first electronic device satisfies the threshold distance from the event location, and whether an elapsed time period between the first time of the data transfer session and the second time of when the event occurred satisfies a threshold period of time; and where the location satisfies the threshold distance and the threshold period of time, transmitting, by the computer system to the first electronic device, the safety notification regarding the event. However, the analogous prior art of White discloses determining, by the computer system, whether the first electronic device satisfies the threshold distance from the event location, and whether an elapsed time period between the first time of the data transfer session [User interaction – i.e. transactional purchase, open account, opening a bank account, paying a security deposit for a lease. See Applicant’s Specification Para 0005, “The crime data may comprise a time of the crime. The method may further comprise determining a period of time between determining the user location and the time of the crime, and transmitting the safety notification comprises transmitting the safety notification when the period of time is less than a crime window.”; See also Applicant’s Specification 0052-0065; specifically, Para 0052, wherein the “the computer system generating a safety notification relating to the safety of an entity at a based on event data related to a location of an entity. For example, the entity may have recently been associated with an interaction that included geolocation data (e.g., recently been involved in or initiated an interaction)”] and the second time of when the event occurred satisfies a threshold period of time; and where the location satisfies the distance and the period of time, transmitting, by the computer system to the first electronic device, the safety notification regarding the event (See at least C6L14-C6L34, “In addition to alerting events to mobile devices based on geographical location, alert messages may be sent based on time periods spent by mobile users in a particular geographical location. For example, alert messages may be sent only to mobile devices that have passed through or are registered with a service provider site [Examiner considers mobile registration to be the interaction/ data transmission] within a certain period of time [Threshold is beginning and end period of “with a certain period of time]. Examples of periods of time include months, weeks, days, hours, minutes, and the like. In this way, alerts may be sent to mobile devices that are within the reach of a service provider site for a specific period of time. For example, if an accident occurred in a particular geographical location half an hour ago, alert messages may be sent to mobile device that have passed through or are registered with a service provider site located within a certain distance of the event for the past half hour, such that mobile users in the vicinity of the accident may take preventative action to avoid the scene. In order to identify mobile devices based on a period of time, it is preferable to store mobile identification numbers (MINs) associated with each service provider site for a period of time in the service provider site, a repository, or a database.”) Therefore, before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have included determining, by the computer system, whether the first electronic device satisfies the threshold distance from the event location, and whether an elapsed time period between the first time of the data transfer session and the second time of when the event occurred satisfies a threshold period of time; and where the location satisfies the distance and the period of time, transmitting, by the computer system to the first electronic device, the safety notification regarding the event, as disclosed by White in the system disclosed by deCharms, for the advantage of providing a method/system of transmitting a safety notification, with the ability to increase efficiency and effectiveness of the system/ method by incorporating a variety of trigger limits to control the type and quantity of safety notifications a user receives (decreasing the chances of information overload) (See KSR [127 S Ct. at 1739] “The combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results.”). As per Claims 2 (1) and 13 (12), deCharms discloses wherein the event comprises one of a crime, traffic, emergency, or weather (See at least Para 0191-0196, Para 0260; See also Para 0005 and 0282). As per Claims 3 (2) and 14 (13), deCharms discloses wherein the event comprises a crime, the event data comprises crime data, and the event location comprises a crime location (See at least Para 0191-0196). As per Claims 4 (1) and 15 (12), deCharms discloses wherein the session information includes geolocation data (See at least Para 0280). As per Claim 5 (3), deCharms discloses wherein the crime data is received from a public database (See at least Para 0147-0148; See also Para 0191-0196, Para 0247). As per Claims 6 (3) and 16 (14), deCharms discloses wherein the safety notification comprises at least one of a distance, a type of crime, recommended safety precaution, or elapsed time since the crime (See at least Para 0191-0196, Para 0260, and Para 0284). As per Claim 7 (3), deCharms discloses determining a distance between the crime location and the location; and wherein transmitting the safety notification is based at least in part on the distance being less than the threshold distance (See at least Para 0191-0196, Para 0260, and Para 0284). As per Claim 8 (7), deCharms discloses wherein the threshold distance is based at least in part on at least one of a type of the crime or severity of the crime (See at least Para 0260, “Additional and/or alternative data sources can be used to provide geotargeted alerts to users who are located within one or more relevant geographic locations. For example, data sources providing information about emergencies (e.g., national emergency monitoring system) and/or weather-related events (e.g., weather/meteorological systems) can be accessed or can push information to this system and, when an event with at least a threshold predicted or occurring level of severity is identified, users that are located inside or within a selected distance from the affected area can receive an alert (e.g., message, recorded message, push notification) to inform them of the event, and people whom they have designated (for example their friends) can also receive a notification.”). As per Claim 17 (14), deCharms discloses wherein: the memory comprises additional computer-executable instructions and the processor is further configured to determine a distance between the crime location and the location; transmitting the safety notification is based at least in part on the distance being less than the threshold distance; and the threshold distance is based at least in part on at least one of a type and severity of crime of the crime (See at least Para 0191-0196, Para 0260, Para 0284). As per Claim 19 (14), deCharms discloses wherein the crime data comprises a time of the crime; the memory comprises additional computer-executable instructions and the processor is further configured to: determine a period of time between determining the location and the time of the crime; and transmit the safety notification comprises transmitting the safety notification when the period of time is less than a threshold period of time (See at least Para 0194). As per Claim 23 (1), deCharms discloses wherein the session information includes location information provided as an input in the data transfer session (See at least Para 0280). As per Claim 25 (1), deCharms discloses wherein determining the threshold distance includes adjusting the threshold distance based at least in part on the severity (Para 0260 and 0284-0286). Allowable Subject Matter Claims 11 and 24 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Response to Arguments Applicant’s arguments filed on 9/11/2026, with respect to Claims 1-8, 12-17, 19-20, 23, and 25, have been considered but are moot based on the new grounds of rejection. The rejection is Non-Final. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the PTO-892 Notice of References Cited. The Examiner suggests the applicant review all of these documents before submitting any amendments. Greene et al. (US 2022/0158982 a1) - See at least Figs.1-8; Para 0033, “During (or after) the assessment of the user device 106, all or part of the device profile 108 information may be transmitted to the Identity Theft Protection Service 110 (ITPS), which as will be discussed below, can be utilized together with a generated Digital ID 114 to monitor and detect various online activities related to the user 102, such as new account openings, change of address requests, loan applications, social media activities, order transactions, payment transactions, account logins, etc.”; Para 0034, “The enrollment process may include the creation of an account for the user 102 by the Identity Monitoring Service 104. Accordingly, a unique User ID comprising an alphanumeric string, for example, may be associated with the enrolled user 102. This User ID may be transmitted by the Identity Monitoring Service 104 to the ITPS 110. The ITPS 110 may utilize the User ID for association with a generated Digital ID 114, and the User ID may be used to identify the associated user 102 when alerts are communicated back to the Identity Monitoring Service 102 upon detection via the Digital Identity Network (DIN) 132 of an online event related to the user 102, which will be further discussed below. In certain exemplary implementations, the User ID utilized by the system 100 can differ from a username that the user 102 utilizes to login to the Identity Monitoring Service 104.”; Para 0035 “As depicted in FIG. 1, the DIN 132 can communicate with servers 122 corresponding to a variety of businesses and/or governmental agencies that provide online interactions with their customers 134 via a website monitoring API 126 integrated into respective websites 124. The website monitoring API 126 may be configured to communicate certain identifying information about the customer 134 and/or the customer's device 136 to the DIN 132 responsive to online activities (account openings, transactions, etc.,) conducted via the website 124. In response, and in certain exemplary implementations, the DIN 132 may communicate this information to the ITPS 110, which may check for correlation with any of the previously generated Digital IDs 114, which may correspond to enrolled users 102 and/or user devices 106 for which a device profile 108 was obtained.”; Para 0036 “In certain implementations, an alert identifying the User ID may be sent to the Identity Monitoring Service 104 when certain events occur that are indicative of possible fraudulent use of an enrolled user's 102 identity information, such as (but not limited to) new account openings, change of address requests, loan applications, social media activities, order transactions, payment transactions, account logins, etc. Accordingly, the alerts can provide timely information for the Identity Monitoring Service 104 to stem identity theft activities and prevent further related damage. In some implementations, the alerts of the (potentially suspicious) activity may also be provided directly to enrolled users 102 (via their user device 106, for example) so that the enrolled user 102 may indicate that the alert corresponds to a legitimate use of their identity.”; Para 0037, “In accordance with certain exemplary implementations of the disclosed technology, when an enrolled user 102 is also the customer 134 who is accessing a business website 124 with a device 136 that has been previously associated with the user's 102 Digital ID 114, the system may not generate an alert. However, in some instances, if the device 136 location information differs from a region of the enrolled user 102 residence (i.e., a different country, or a region known to correspond to high crime rates), the alert may be generated. In certain implementations, when an account login is detected at a first location, then another event using the same login information is detected at second location exceed a threshold distance from the first location for a given period, an alert may be generated. In accordance with certain exemplary implementations of the disclosed technology, when an enrolled user 102 uses a device 136 that is either new or that differs from an enrolled device 106 (for which the device profile 108 is known), an alert may be generated.”; Para 0046, “As a first step of the process 200, the ITPS 110 may call an attribute query API 133, for example, to execute a policy with alert criteria. In certain exemplary implementations, the attribute query API 133 may selectively commit the Digital ID 114 to the DIN 132. In certain exemplary implementations, the alert criteria may include location-based criteria. For example, when an account login is detected at a first location, then another event using the same login information is detected at second location exceed a threshold distance from the first location for a given period, an alert may be generated.” Mcdougall et al. (US 2021/0258756 A1) - See at least Figs.1-3; Para 0029, “Such details can be reviewed and one or more attributes of the alert, such as the location attribute, the risk score 192, the temporal attribute, etc., can be altered accordingly and an updated alert may be generated for approval and publication.”; Para 0035, “The risk alert 190, transmitted or issued by the risk processing platform 110 is received by the alerts receiver 202 and provided to an alerts analyzer 204 for the extraction of the alert attributes. The alerts analyzer 204 extracts the location attributes 242 and the time-related or temporal attributes 244 of the risk alert 190 in addition to other data such as the risk score 192 of the risk alert 190 and the suggestions for managing the emergency, etc. The alerts analyzer 204 employs the extracted data to determine if the risk alert 190 should be displayed to the user. The risk score 192 of the risk alert 190 can be further optimized by the risk score updater 206 to generate a user-specific risk score 292 based on various factors obtained from the local data of the client device 130-1. The user-specific risk score 292 is compared to a predetermined score threshold by the alerts analyzer 204 to determine if the alert should be displayed to the user or if the risk alert 190 should be deleted without displaying it to the user.”; See at least Para 0042, “The location attributes 322 and the temporal attributes 344 extracted from the risk alert, 190 employed by the risk score updater 206 to generate a user-specific risk score 352 by updating or optimizing the risk score 192. The temporal attributes 344 from the risk alert 190 are compared by the risk score updater 206 to a current date/time obtained from the client device 130-1. If the current date and time coincides with or is within a predetermined time threshold of the temporal attributes 344, the risk score 192 can be increased by a factor that is inversely proportional to the difference between the current date and time and the temporal attributes 344.”; and Para 0047. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN P OUELLETTE whose telephone number is (571)272-6807. The examiner can normally be reached on M-F 8am-6pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynda C Jasmin, can be reached at telephone number (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. October 10, 2026 /JONATHAN P OUELLETTE/Primary Examiner, Art Unit 3629
Read full office action

Prosecution Timeline

Show 10 earlier events
Dec 30, 2025
Non-Final Rejection mailed — §103
Apr 10, 2026
Applicant Interview (Telephonic)
Apr 10, 2026
Examiner Interview Summary
May 22, 2026
Response Filed
Jul 01, 2026
Final Rejection mailed — §103
Sep 11, 2026
Request for Continued Examination
Sep 16, 2026
Response after Non-Final Action
Oct 14, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12755292
DATA PROCESSING SYSTEMS FOR FULFILLING DATA SUBJECT ACCESS REQUESTS AND RELATED METHODS
4y 3m to grant Granted Oct 06, 2026
Patent 12755232
APPARATUS AND METHODS FOR TRANSPORT OPTIMIZATION
3y 11m to grant Granted Oct 06, 2026
Patent 12754062
TRUCK SCALE MANAGEMENT SYSTEM AND METHOD
2y 7m to grant Granted Oct 06, 2026
Patent 12737804
METHOD FOR CREATING COMMODITY ASSETS FROM UNREFINED COMMODITY RESERVES UTILIZING BLOCKCHAIN AND DISTRIBUTED LEDGER TECHNOLOGY
2y 7m to grant Granted Sep 15, 2026
Patent 12724686
Duplication Avoidance For Mutable Event Based Metrics
2y 9m to grant Granted Sep 01, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

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

5-6
Expected OA Rounds
66%
Grant Probability
96%
With Interview (+29.5%)
3y 8m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 1165 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