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-19 of U.S. Patent No. 12,017, 583 in view of Bowne (US 2013/0006674 A1) in view of Bryer (US 10,445,758 B1), and further in view of Abramson (US 2012/0071151 A1).
Subject claims
Patented claims
1. A method comprising:
receiving, by one or more processors, electronic signals generated by one or more sensors of a computing device [i.e. mobile device] disposed in a vehicle during a drive,
wherein the electronic signals indicate motion data measured in a reference frame of the computing device;
transforming, by the one or more processors, the motion data measured in the reference frame of the computing device to produce acceleration vectors for the vehicle in a reference frame of the vehicle;
detecting, by the one or more processors using the acceleration vectors for the vehicle, a hard braking event;
alerting, by the one or more processors, a driver of the vehicle to the hard braking event in real time in response to detecting the hard braking event, wherein the driver is alerted at a first time;
detecting a subsequent hard braking event at a subsequent time after the first time;
determining, in response to detecting the subsequent hard braking event, that at least one of: an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time; or
a number of events detected between the first time and the subsequent time is greater than or equal to a predefined number of events; and
alerting the driver to the subsequent hard braking event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time, the number of events is greater than or equal to the predefined number of events, or both.
1. A method comprising:
receiving, by one or more processors, electronic signals generated by one or more sensors of a mobile device disposed in a vehicle during a drive,
wherein the electronic signals indicate motion data measured in a reference frame of the mobile device;
transforming, by the one or more processors, the motion data measured in the reference frame of the mobile device to produce acceleration vectors for the vehicle in a reference frame of the vehicle;
detecting, by the one or more processors using the acceleration vectors for the vehicle, a hard braking event;
[detecting, by the one or more processors using the motion data, and the acceleration vectors for the vehicle, movement of the mobile device with respect to the reference frame of the vehicle indicating a distracted driving event; detecting, by the one or more processors, a correlation between the distracted driving event and the hard braking event, wherein the correlation indicates that the hard braking event was in response to the distracted driving event; ]
alerting, by the one or more processors, a user of the mobile device, through the mobile device, of the hard braking event [[and the distracted driving event]] in real time in response to detecting the correlation, wherein the user is alerted at a first time;
detecting a subsequent correlation between a subsequent distracted driving event and a subsequent hard braking event at a subsequent time during the drive;
determining that an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time in response to detecting the subsequent correlation; and
alerting the user of the mobile device, through the mobile device, of the subsequent hard braking event and the subsequent distracted driving event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time.
2. The method of claim 1, further comprising:
detecting, by the one or more processors using the motion data and the acceleration vectors for the vehicle, a driving event that occurred prior to detecting the hard braking event, wherein the driving event is a different type of event than the hard braking event; and
detecting, by the one or more processors,
a correlation between the driving event and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation.
Claim 1:…
detecting, by the one or more processors using the motion data, and the acceleration vectors for the vehicle, movement of the mobile device with respect to the reference frame of the vehicle indicating a distracted driving event;
detecting, by the one or more processors, a correlation between the [distracted] driving event and the hard braking event, wherein the correlation indicates that the hard braking event was in response to the distracted driving event;
3. The method of claim 2, wherein: the computing device is a mobile device; and
detecting the driving event comprises detecting movement of the mobile device with respect to the reference frame of the vehicle indicative of a distracted driving event.
Claim 1:…
wherein the electronic signals indicate motion data measured in a reference frame of the mobile device
detecting, by the one or more processors using the motion data, and the acceleration vectors for the vehicle, movement of the mobile device with respect to the reference frame of the vehicle indicating a distracted driving event;
4. The method of claim 2, wherein detecting the driving event comprises: determining a speed of the vehicle; and detecting that the speed of the vehicle is indicative of a speeding event.
See Patented claim 1 in view of Bowne, Bryer, and Abramson.
5. The method of claim 2, wherein the driving event is a cornering event or an acceleration event.
See Patented claim 1 in view of Bowne, Bryer, and Abramson.
6. The method of claim 1, further comprising: retrieving, by the one or more processors, contextual data for the drive; and
detecting, by the one or more processors, a correlation between the contextual data and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation.
Claim 1:…
detecting, by the one or more processors, a correlation between the [distracted] driving event and the hard braking event, wherein the correlation indicates that the hard braking event was in response to the distracted driving event;
7. The method of claim 6, wherein the contextual data comprises at least one of: weather data; a time of day of the drive; location information; map data; or traffic data.
See Patented claim 1 in view of Bowne, Bryer, and Abramson.
8. The method of claim 1, wherein the predefined number of events, the predefined period of time, or both are set based on an input from a user of the computing device.
2. The method of claim 1 wherein the user of the mobile device is alerted of the subsequent hard braking event and the subsequent distracted driving event in further response to determining that a predefined number of events have been detected between the first time and the subsequent time, and wherein the predefined number of events is set on the mobile device or received from a server.
4. The method of claim 1 further comprising:
receiving, before the first time, a first input from the user of the mobile device that enables alerts,
wherein the user is alerted at the first time in further response to determining that the alerts are enabled; or
receiving, after the drive is complete, a second input from the user of the mobile device that disables future alerts.
9. The method of claim 1,
wherein the predefined number of events, the predefined period of time, or both are received from a server.
2. The method of claim 1 …
wherein the predefined number of events is set on the mobile device or received from a server.
10. The method of claim 1, further comprising:
receiving, before the first time, a first input from a user of the computing device that enables alerts, wherein the driver is alerted at the first time in further response to determining that the alerts are enabled.
4. The method of claim 1 further comprising:
receiving, before the first time, a first input from the user of the mobile device that enables alerts, wherein the user is alerted at the first time in further response to determining that the alerts are enabled; or receiving, after the drive is complete, a second input from the user of the mobile device that disables future alerts.
11. The method of claim 1, wherein the motion data is collected during an initial time period that includes the first time and the subsequent time, the method further comprising:
collecting additional motion data from the one or more sensors of the computing device during a subsequent time period, wherein the subsequent time period is after the initial time period;
detecting, using the additional motion data and at least one of the one or more processors or a server, a change in a rate of hard braking events during the subsequent time period; and
modifying future alerts based on the detection of the change in the rate of hard braking events during the subsequent time period.
6. The method of claim 1 wherein the motion data is collected during an initial time period that includes the first time and the subsequent time, the method further comprising:
collecting additional motion data from the one or more sensors of the mobile device during a subsequent time period, wherein the subsequent time period is after the initial time period;
detecting, using the additional motion data and at least one of the one or more processors or a server, a change in a rate of hard braking events during the subsequent time period; and
modifying future alerts based on the detection of the change in the rate of hard braking events during the subsequent time period.
12. The method of claim 11, wherein modifying the future alerts comprises modifying a timing of notifying the driver of a future hard braking event.
7. The method of claim 6 wherein modifying the future alerts comprises modifying a timing of notifying the user of a future hard braking event.
13. The method of claim 1, wherein alerting the driver of the hard braking event comprises delivery, using the computing device, of at least one of: an audio alert, a haptic alert, or a visual alert.
8. The method of claim 1 wherein alerting the user of the hard braking event and the distracted driving event comprises delivery, using the mobile device, of at least one of an audio alert or a haptic alert.
14. The method of claim 1, wherein the one or more sensors of the computing device comprise an accelerometer, and detecting the hard braking event comprises detecting a rapid deceleration of the vehicle.
10. The method of claim 1 wherein the one or more sensors of the mobile device comprises an accelerometer and detecting the hard braking event comprises detecting a rapid deceleration of the vehicle using acceleration vectors for the vehicle determined from the motion data.
15. A computing device comprising
a memory;
a motion data unit comprising one or more sensors configured to generate electronic signals indicative of motion data measured in a reference frame of the computing device; and
a processor coupled to the memory, wherein the processor is configured to perform operations including:
receiving the electronic signals from the motion data unit while the computing device is disposed in a vehicle during a drive;
transforming, from the electronic signals, the motion data measured in the reference frame of the computing device to produce acceleration vectors for the vehicle in a reference frame of the vehicle;
detecting, using the acceleration vectors for the vehicle, a hard braking event;
alerting a driver of the vehicle to the hard braking event in real time in response to detecting the hard braking event, wherein the driver is alerted at a first time;
detecting a subsequent hard braking event at a subsequent time after the first time;
determining, in response to detecting the subsequent hard braking event, that at least one of: an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time; or a predefined number of events have been detected between the first time and the subsequent time; and
alerting the driver to the subsequent hard braking event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time, the predefined number of events have been detected, or both.
14. A mobile device comprising:
a memory;
a motion data unit comprising one or more sensors configured to generate electronic signals indicative of motion data measured in a reference frame of the mobile device; and
a processor coupled to the memory, wherein the processor is configured to perform operations including:
receiving the electronic signals from the motion data unit while the mobile device is disposed in a vehicle during a drive;
transforming, from the electronic signals, the motion data measured in the reference frame of the mobile device to produce acceleration vectors for the vehicle in a reference frame of the vehicle;
detecting, using the acceleration vectors for the vehicle, a hard braking event;
detecting, using the motion data and the acceleration vectors for the vehicle, movement of the mobile device with respect to the reference frame of the vehicle indicating a distracted driving event; detecting a correlation between the distracted driving event and the hard braking event, wherein the correlation indicates that the hard braking event was in response to the distracted driving event;
alerting a user of the mobile device, through the mobile device, of the hard braking event and the distracted driving event in real time in response to detecting the correlation, wherein the user is alerted at a first time;
detecting a subsequent correlation between a subsequent distracted driving event and a subsequent hard braking event at a subsequent time during the drive;
determining that an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time in response to detecting the subsequent correlation; and
alerting the user of the mobile device, through the mobile device, of the subsequent hard braking event and the subsequent distracted driving event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time.
16. The computing device of claim 15, wherein the operations further include:
detecting, using the motion data and the acceleration vectors for the vehicle, a driving event that occurred prior to detecting the hard braking event, wherein the driving event is one of a distracted driving event, a speeding event, a cornering event, or an acceleration event; and detecting a correlation between the driving event and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation.
Claim 14: ...
detecting, using the motion data and the acceleration vectors for the vehicle, movement of the mobile device with respect to the reference frame of the vehicle indicating a distracted driving event; detecting a correlation between the distracted driving event and the hard braking event, wherein the correlation indicates that the hard braking event was in response to the distracted driving event;
17. The computing device of claim 15, wherein the operations further include: retrieving contextual data for the drive, wherein the contextual data comprises at least one of: weather data; a time of day of the drive; location information; map data; or traffic data; and detecting a correlation between the contextual data and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation.
See Patented claim 1 in view of Bowne, Bryer, and Abramson.
18. One or more non-transitory computer-readable storage media storing instructions that, upon execution by one or more processors of a computing device, cause the one or more processors to perform operations comprising: receiving electronic signals generated by one or more sensors of the computing device while the computing device is disposed in a vehicle during a drive, wherein the electronic signals indicate motion data measured in a reference frame of the computing device; transforming the motion data measured in the reference frame of the computing device to produce acceleration vectors for the vehicle in a reference frame of the vehicle; detecting, using the acceleration vectors for the vehicle, a hard braking event; alerting a driver of the vehicle to the hard braking event in real time in response to detecting the hard braking event, wherein the driver is alerted at a first time; detecting a subsequent hard braking event at a subsequent time after the first time; determining, in response to detecting the subsequent hard braking event, that at least one of: an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time; or a predefined number of events have been detected between the first time and the subsequent time; and alerting the driver to the subsequent hard braking event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time, the predefined number of events have been detected, or both.
See Patented Claim 14
19. The one or more non-transitory computer-readable storage media of claim 18, wherein the operations further comprise: detecting, using the motion data and the acceleration vectors for the vehicle, a driving event that occurred prior to detecting the hard braking event, wherein the driving event is one of a distracted driving event, a speeding event, a cornering event, or an acceleration event; and detecting a correlation between the driving event and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation.
See Patented Claim 14
20. The one or more non-transitory computer-readable storage media of claim 18, wherein the operations further comprise: retrieving contextual data for the drive, wherein the contextual data comprises at least one of: weather data during the drive; a time of day of the drive; location information; map data; or traffic data; and detecting a correlation between the contextual data and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation.
See Patented claim 1 in view of Bowne, Bryer, and Abramson.
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.
Claim(s) 1, 8-15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bowne (US 2013/0006674 A1) and further in view of Bryer (US 10,445,758 B1)
Consider claim 1, Bowne teaches, a method comprising:
receiving, by one or more processors (31), electronic signals generated by one or more sensors (34) of a computing device (10) disposed in a vehicle (12) during a drive, wherein the electronic signals indicate motion data measured in a reference frame of the computing device, Bowne teaches, “a mobile device, such as a smartphone, is used to collect and transmit vehicle operation data” See ¶ 0008; Bowne teaches, “FIG. 2 illustrates example components of mobile device 10 relevant to the driving analysis system discussed herein, according to certain embodiments. As shown, mobile device 10 may include a memory 30, processor 32, one or more sensors 34, a display 36, and input/output devices 38.” See ¶ 0052. Bowne teaches, “[s]ensors 34 may include any one or more devices for detecting information regarding a driver's driving behavior and/or the driving environment. For example, as discussed above, sensors 34 may include an accelerometer 54 configured to detect acceleration of the mobile device 10 (and thus, the acceleration of a vehicle in which mobile device 10 is located) in one or more directions, e.g., the x, y, and z directions.” See ¶ 0056.
transforming, by the one or more processors, the motion data measured in the reference frame of the computing device to produce acceleration vectors for the vehicle in a reference frame of the vehicle, Bowne teaches, “mobile device 10 may include a built-in accelerometer configured to detect acceleration in one or more directions (e.g., in the x, y, and z directions).” See ¶ 0048;
detecting, by the one or more processors using the acceleration vectors for the vehicle, a hard braking event, Bowne teaches, “[p]rocessor 32 may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application specific integrated controller (ASIC), electrically-programmable read-only memory (EPROM), or a field-programmable gate array (FPGA), or any other suitable processor(s), and may be generally operable to execute driving analysis application 50, as well as providing any other functions of mobile device 10.” See ¶ 0055. Bowne teaches, “solid state compass, with two or three magnetic field sensors, may provide data to a microprocessor to calculate direction using trigonometry.” See ¶ 0056. Bowne teaches, “data processing module 42 may define multiple levels of severity for each type (or certain types) of notable driving events. For example, module 42 may define the following levels of notable braking: (1) significant braking, and (2) extreme braking” See ¶ 0083. Bowne teaches, “[a]cceleration Data from accelerometer or sensor used for determining speed, stops, acceleration, and turns; (2) G-force Data for very high speed brakes, hard brakes, smooth brakes, very high speed turns, hard turns, smooth turns, very high speed acceleration, hard acceleration, or smooth acceleration” See ¶ 0209. Bowne teaches, “remote data storage system 152 comprises a server 154 and a database 155. The database 155 stores various data and information transmitted to it via the server 154, including: data received from a mobile device 156, data calculated by a mobile device prior to receiving 157, and captured and available data for property and casualty rating 158.” See ¶ 0197. Bowne teaches, “[c]ollected data is automatically transmitted to the server 154, described more fully below. During the whole process certain data is sent to the server 154 from the mobile device 10, and similarly after calculations are made, data may be received by the mobile device 10 from the server 154.” See ¶ 0200. Bowne teaches, “[d]ata is transmitted 188 from the mobile device 10 to the server 154 of the remote data storage system 152 via a network 144. Every 1 minute of data is sent 189 to the server for backend calculations if the network is readily available.” See ¶ 0209;
alerting, by the one or more processors, a driver of the vehicle to the hard braking event in real time in response to detecting the hard braking event, wherein the driver is alerted at a first time, Bowne teaches, “[p]rocessor 32 may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application specific integrated controller (ASIC), electrically-programmable read-only memory (EPROM), or a field-programmable gate array (FPGA), or any other suitable processor(s), and may be generally operable to execute driving analysis application 50, as well as providing any other functions of mobile device 10.” See ¶ 0055. Bowne teaches, “solid state compass, with two or three magnetic field sensors, may provide data to a microprocessor to calculate direction using trigonometry.” See ¶ 0056. Bowne teaches, “data processing module 42 may define multiple levels of severity for each type (or certain types) of notable driving events. For example, module 42 may define the following levels of notable braking: (1) significant braking, and (2) extreme braking” See ¶ 0083. Bowne teaches, “[a]cceleration Data from accelerometer or sensor used for determining speed, stops, acceleration, and turns; (2) G-force Data for very high speed brakes, hard brakes, smooth brakes, very high speed turns, hard turns, smooth turns, very high speed acceleration, hard acceleration, or smooth acceleration” See ¶ 0209. Bowne teaches, “remote data storage system 152 comprises a server 154 and a database 155. The database 155 stores various data and information transmitted to it via the server 154, including: data received from a mobile device 156, data calculated by a mobile device prior to receiving 157, and captured and available data for property and casualty rating 158.” See ¶ 0197. Bowne teaches, “[c]ollected data is automatically transmitted to the server 154, described more fully below. During the whole process certain data is sent to the server 154 from the mobile device 10, and similarly after calculations are made, data may be received by the mobile device 10 from the server 154.” See ¶ 0200. Bowne teaches, “[d]ata is transmitted 188 from the mobile device 10 to the server 154 of the remote data storage system 152 via a network 144. Every 1 minute of data is sent 189 to the server for backend calculations if the network is readily available.” See ¶ 0209;
detecting a subsequent hard braking event at a subsequent time after the first time, Bowne teaches, “steps 82-88 (or at least portions of such steps) may be executed in real time or substantially in real time such that steps 82-88 are continuously performed, or repeated, during a particular data collection session. In such embodiments, at step 86 data may be prepared for subsequent display rather than being displayed in real time,” See ¶ 0116, nonetheless, in an analogous art, Bryer teaches, “mobile computing device may be configured to include a trip monitoring application… A trip monitoring application may be configured to be installed at a mobile computing device. The trip monitoring application may be configured to, in operation, automatically detect when a trip in a vehicle has begun, collect trip information during the trip, and derive additional trip information based on the trip information collected upon termination of the trip. A performance scoring module may be configured to, in operation, determine a performance score based, at least in part, on the additional information derived from the trip information collected during the trip.” Col. 2 lines 11-22. Bryer teaches, “a trip monitoring device may be a mobile computing device such as a mobile cellular telephone or a tablet computing device that is configured to collect driving behavior data during a trip…. The mobile computing device 900 shown by way of example in FIG. 9 includes an accelerometer 908, a magnetometer 910, a gyroscope 912, a barometer 914, a GPS module 916, and a communication module 918.” Col. 28 lines 34-57.
Bryer teaches, “FIG. 10I another example of an interface display 1000i of a trip monitoring application is shown. The interface 1000i may present various user-adjustable settings. The user-adjustable settings, in this example, include sleep mode settings and trip notification settings. The interface display 1000i may include a toggle button 1054 to toggle activation of the sleep mode as well as an input element 1056 for setting a sleep duration. Upon activation of the sleep mode, a sleep timer will start that is set to the selected sleep duration. While the sleep mode is active, the trip detection feature of the trip monitoring application may be deactivated. Upon expiration of the sleep timer, the trip monitoring application will reactivate the trip detection feature such that the trip monitoring application will again initiate trip monitoring upon detection of a trip. A user may activate the sleep mode to prevent trip monitoring during time periods when the user will not be driving. The interface display 1000i may also include a toggle button 1058 to toggle activation of push notifications as well as an input element 1060 for setting a push notification frequency. In some example implementations, the driving analysis and reward system may be configured to push trip performance results to the mobile computing device upon completion of a trip. Activating the push notification feature allows the trip monitoring application to receive trip performance information without explicitly requesting it from the driving analysis and reward system. When the push notification feature is deactivated, the driving analysis and reward system may not provide trip performance information to the trip monitoring application unless the trip monitoring application submits a request for it. The user may also be able to set the frequency for how often the driving analysis and reward system may push notifications to the trip monitoring application, e.g., at the completion of each trip, at the end of the day, and so forth. The driving analysis and reward system may maintain a queue of notifications to push to the trip monitoring application and transmit the queued notifications at the beginning of the next frequency period.” Col. 47 lines 1-24.
With respect to:
determining, in response to detecting the subsequent hard braking event, that at least one of:
an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time; or
a number of events detected between the first time and the subsequent time is greater than or equal to a predefined number of events,
Bryer teaches, “FIG. 10I another example of an interface display 1000i of a trip monitoring application is shown. The interface 1000i may present various user-adjustable settings. The user-adjustable settings, in this example, include sleep mode settings and trip notification settings. The interface display 1000i may include a toggle button 1054 to toggle activation of the sleep mode as well as an input element 1056 for setting a sleep duration. Upon activation of the sleep mode, a sleep timer will start that is set to the selected sleep duration. While the sleep mode is active, the trip detection feature of the trip monitoring application may be deactivated. Upon expiration of the sleep timer, the trip monitoring application will reactivate the trip detection feature such that the trip monitoring application will again initiate trip monitoring upon detection of a trip. A user may activate the sleep mode to prevent trip monitoring during time periods when the user will not be driving. The interface display 1000i may also include a toggle button 1058 to toggle activation of push notifications as well as an input element 1060 for setting a push notification frequency. In some example implementations, the driving analysis and reward system may be configured to push trip performance results to the mobile computing device upon completion of a trip. Activating the push notification feature allows the trip monitoring application to receive trip performance information without explicitly requesting it from the driving analysis and reward system. When the push notification feature is deactivated, the driving analysis and reward system may not provide trip performance information to the trip monitoring application unless the trip monitoring application submits a request for it. The user may also be able to set the frequency for how often the driving analysis and reward system may push notifications to the trip monitoring application, e.g., at the completion of each trip, at the end of the day, and so forth. The driving analysis and reward system may maintain a queue of notifications to push to the trip monitoring application and transmit the queued notifications at the beginning of the next frequency period.” Col. 47 lines 1-24 See Fig. 10I.
alerting the driver to the subsequent hard braking event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time, the number of events is greater than or equal to the predefined number of events, or both, Bryer teaches, “FIG. 10I another example of an interface display 1000i of a trip monitoring application is shown. The interface 1000i may present various user-adjustable settings. The user-adjustable settings, in this example, include sleep mode settings and trip notification settings. The interface display 1000i may include a toggle button 1054 to toggle activation of the sleep mode as well as an input element 1056 for setting a sleep duration. Upon activation of the sleep mode, a sleep timer will start that is set to the selected sleep duration. While the sleep mode is active, the trip detection feature of the trip monitoring application may be deactivated. Upon expiration of the sleep timer, the trip monitoring application will reactivate the trip detection feature such that the trip monitoring application will again initiate trip monitoring upon detection of a trip. A user may activate the sleep mode to prevent trip monitoring during time periods when the user will not be driving. The interface display 1000i may also include a toggle button 1058 to toggle activation of push notifications as well as an input element 1060 for setting a push notification frequency. In some example implementations, the driving analysis and reward system may be configured to push trip performance results to the mobile computing device upon completion of a trip. Activating the push notification feature allows the trip monitoring application to receive trip performance information without explicitly requesting it from the driving analysis and reward system. When the push notification feature is deactivated, the driving analysis and reward system may not provide trip performance information to the trip monitoring application unless the trip monitoring application submits a request for it. The user may also be able to set the frequency for how often the driving analysis and reward system may push notifications to the trip monitoring application, e.g., at the completion of each trip, at the end of the day, and so forth. The driving analysis and reward system may maintain a queue of notifications to push to the trip monitoring application and transmit the queued notifications at the beginning of the next frequency period.” Col. 47 lines 1-24 See Fig. 10I.
It would have been obvious to one of ordinary skilled in the art at the time of invention to modify the invention of Bowne and allow the user to set the frequency of the driver’s alert notification as well as enable and disable to the driver’s alert notifications on their mobile device as suggested by Bryer, Col. 47 lines 1-24, in an effort to eliminate unnecessary alerts and designing an efficient and user friendly system.
Consider claim 8, the method of claim 1, wherein the predefined number of events, the predefined period of time, or both are set based on an input from a user of the computing device, Bryer teaches, “FIG. 10I another example of an interface display 1000i of a trip monitoring application is shown. The interface 1000i may present various user-adjustable settings. The user-adjustable settings, in this example, include sleep mode settings and trip notification settings. The interface display 1000i may include a toggle button 1054 to toggle activation of the sleep mode as well as an input element 1056 for setting a sleep duration. Upon activation of the sleep mode, a sleep timer will start that is set to the selected sleep duration. While the sleep mode is active, the trip detection feature of the trip monitoring application may be deactivated. Upon expiration of the sleep timer, the trip monitoring application will reactivate the trip detection feature such that the trip monitoring application will again initiate trip monitoring upon detection of a trip. A user may activate the sleep mode to prevent trip monitoring during time periods when the user will not be driving. The interface display 1000i may also include a toggle button 1058 to toggle activation of push notifications as well as an input element 1060 for setting a push notification frequency. In some example implementations, the driving analysis and reward system may be configured to push trip performance results to the mobile computing device upon completion of a trip. Activating the push notification feature allows the trip monitoring application to receive trip performance information without explicitly requesting it from the driving analysis and reward system. When the push notification feature is deactivated, the driving analysis and reward system may not provide trip performance information to the trip monitoring application unless the trip monitoring application submits a request for it. The user may also be able to set the frequency for how often the driving analysis and reward system may push notifications to the trip monitoring application, e.g., at the completion of each trip, at the end of the day, and so forth. The driving analysis and reward system may maintain a queue of notifications to push to the trip monitoring application and transmit the queued notifications at the beginning of the next frequency period.” Col. 47 lines 1-24.
Consider claim 9, the method of claim 1, wherein the predefined number of events, the predefined period of time, or both are received from a server, Bowne teaches, “remote data storage system 152 comprises a server 154 and a database 155. The database 155 stores various data and information transmitted to it via the server 154, including: data received from a mobile device 156, data calculated by a mobile device prior to receiving 157, and captured and available data for property and casualty rating 158.” See ¶ 0197. Bowne teaches, “[c]ollected data is automatically transmitted to the server 154, described more fully below. During the whole process certain data is sent to the server 154 from the mobile device 10, and similarly after calculations are made, data may be received by the mobile device 10 from the server 154.” See ¶ 0200. Bowne teaches, “[d]ata is transmitted 188 from the mobile device 10 to the server 154 of the remote data storage system 152 via a network 144. Every 1 minute of data is sent 189 to the server for backend calculations if the network is readily available.” See ¶ 0209. And See Bryer, Col. 47 lines 1-24.
Consider claim 10, the method of claim 1, further comprising: receiving, before the first time, a first input from a user of the computing device that enables alerts, wherein the driver is alerted at the first time in further response to determining that the alerts are enabled, See Bryer, Col. 47 lines 1-24.
Consider claim 11, the method of claim 1, wherein the motion data is collected during an initial time period that includes the first time and the subsequent time, the method further comprising:
collecting additional motion data from the one or more sensors of the computing device during a subsequent time period, wherein the subsequent time period is after the initial time period;
detecting, using the additional motion data and at least one of the one or more processors or a server, a change in a rate of hard braking events during the subsequent time period; and
modifying future alerts based on the detection of the change in the rate of hard braking events during the subsequent time period, See Bryer, Col. 47 lines 1-24.
Consider claim 12, the method of claim 11, wherein modifying the future alerts comprises modifying a timing of notifying the driver of a future hard braking event, See Bryer, Col. 47 lines 1-24.
Consider claim 13, the method of claim 1, wherein alerting the driver of the hard braking event comprises delivery, using the computing device, of at least one of: an audio alert, [a haptic alert], or a visual alert, Bowne teaches, “feedback module 44 may provide audible feedback (e.g., buzzers or other sound effects, or by human recorded or computer-automated spoken feedback) through a speaker of mobile device 10 or the vehicle's speakers, or visual feedback via display 36 of mobile device 10 or other display device of the vehicle. Such real-time audible or visual feedback may distinguish between different types of notable driving events and/or between the severity level of each notable driving event, in any suitable manner. For example, spoken feedback may indicate the type and severity of a notable driving event in real time. Non-spoken audible feedback may indicate the different types and severity of notable driving events by different sounds and/or different volume levels.” See ¶ 0091. Abramson teaches “providing a notification at mobile device 105, may be appropriate even for lower degrees of correlation/deviation” See ¶ 0119.
Consider claim 14, the method of claim 1, wherein the one or more sensors of the computing device comprise an accelerometer, and detecting the hard braking event comprises detecting a rapid deceleration of the vehicle, Bowne teaches, “mobile device 10 may include a built-in accelerometer configured to detect acceleration in one or more directions (e.g., in the x, y, and z directions). As another example, mobile device 10 may include a GPS (global positioning system) device or any other device for tracking the geographic location of the mobile device.” See ¶ 0048 Bowne teaches, “driving analysis application may calculate acceleration, braking, and cornering metrics based on driving behavior data collected by the built-in accelerometer (and/or other collected data).” See ¶ 0049. Bowne teaches, “[d]ata collected every second 187 may include: (1) Acceleration Data from accelerometer or sensor used for determining speed, stops, acceleration, and turns; (2) G-force Data for very high speed brakes, hard brakes, smooth brakes, very high speed turns, hard turns” See ¶ 0209. Bowne teaches, “memory module is preprogrammed with data collection parameters through microprocessor … a trip-based and organized data set including hard and extreme acceleration and deceleration, velocity (in discrete bands)” See ¶ 0007. With respect to rapid deceleration, Bryer also teaches, “braking score may be based on the total number of “hard” deceleration events (e.g., braking events associated with deceleration of 8.0-10 mph/s) and the total number of “extreme” braking events (e.g., braking events associated with deceleration of 10+ mph/s).” col. 34 lines 50-54
Consider claim 15, a computing device comprising a memory;
a motion data unit comprising one or more sensors configured to generate electronic signals indicative of motion data measured in a reference frame of the computing device; and
a processor coupled to the memory, wherein the processor is configured to perform operations including: receiving the electronic signals from the motion data unit while the computing device is disposed in a vehicle during a drive;
transforming, from the electronic signals, the motion data measured in the reference frame of the computing device to produce acceleration vectors for the vehicle in a reference frame of the vehicle;
detecting, using the acceleration vectors for the vehicle, a hard braking event;
alerting a driver of the vehicle to the hard braking event in real time in response to detecting the hard braking event, wherein the driver is alerted at a first time;
detecting a subsequent hard braking event at a subsequent time after the first time;
determining, in response to detecting the subsequent hard braking event, that at least one of:
an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time; or
a predefined number of events have been detected between the first time and the subsequent time; and
alerting the driver to the subsequent hard braking event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time, the predefined number of events have been detected, or both, See rejection of claim 1.
Consider claim 18, one or more non-transitory computer-readable storage media storing instructions that, upon execution by one or more processors of a computing device, cause the one or more processors to perform operations comprising:
receiving electronic signals generated by one or more sensors of the computing device while the computing device is disposed in a vehicle during a drive, wherein the electronic signals indicate motion data measured in a reference frame of the computing device;
transforming the motion data measured in the reference frame of the computing device to produce acceleration vectors for the vehicle in a reference frame of the vehicle;
detecting, using the acceleration vectors for the vehicle, a hard braking event;
alerting a driver of the vehicle to the hard braking event in real time in response to detecting the hard braking event, wherein the driver is alerted at a first time;
detecting a subsequent hard braking event at a subsequent time after the first time;
determining, in response to detecting the subsequent hard braking event, that at least one of:
an elapsed time between the first time and the subsequent time is greater than or equal to a predefined period of time; or
a predefined number of events have been detected between the first time and the subsequent time; and
alerting the driver to the subsequent hard braking event in real time in response to determining that the elapsed time is greater than or equal to the predefined period of time, the predefined number of events have been detected, or both, See rejection of claim 1.
Claims 2-7, 16-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bowne (US 2013/0006674 A1), in view of Bryer (US 10,445,758 B1), and further in view of Abramson (US 2012/0071151 A1).
Consider claim 2, the method of claim 1, further comprising:
detecting, by the one or more processors using the motion data and the acceleration vectors for the vehicle, a driving event that occurred prior to detecting the hard braking event, wherein the driving event is a different type of event than the hard braking event, Bowne teaches, “driving analysis application may identify "notable driving events," such as instances of notable acceleration, braking, and/or cornering, as well as the severity of such events. In some embodiments, the driving analysis application may account for environmental factors, based on collected driving environment data corresponding to the analyzed driving session(s). For example, the identification of notable driving events may depend in part on environmental conditions such as the weather, traffic conditions, road conditions, etc. Thus, for instance, a particular level of braking may be identified as a notable driving event in the rain, but not in dry conditions.” See ¶ 0049; and
detecting, by the one or more processors, a correlation between the driving event and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation, Bowne teaches, “the identification of notable driving events may depend in part on environmental conditions such as the weather, traffic conditions, road conditions, etc. Thus, for instance, a particular level of braking may be identified as a notable driving event in the rain, but not in dry conditions.” See ¶ 0049; nonetheless, in an analogous art, Abramson teaches, “[s]everal solutions have been proposed to address illegal/unsafe cell phone usage by drivers of vehicles. Certain of these approaches seek to utilize a phone's on-board GPS and/or accelerometers to establish the likelihood that the phone is being used within a moving vehicle.” See Abramson ¶ 0008. Abramson teaches, “[m]obile device 105 of in-vehicle user-role determination system 100 includes a control circuit 140 which is operatively connected to various hardware and software components that serve to enable operation of the in-vehicle user-role determination system 100.” See Abramson ¶ 0069. Abramson teaches, “the first input originates from one or more identifying events that are perceptible to at least one of sensors 145, user interface 172, operating system 176, and/or communication interface 150... the first input originates from one or more identifying events that are perceptible to at least one of sensors 145… of mobile device 105, such as an acceleration input perceived by accelerometer 145A and/or a change in orientation input perceived by gyroscope 145B.” See ¶ 0134. Abramson teaches, “[t]he terms ‘identifying event’ and ‘identifying events’ as used herein are intended to encompass one or more occurrences or instances of events, stimuli, or phenomena, including explicitly the perceived coordinated or correlated occurrence or instance of two or more such events, stimuli, and/or phenomena, such as those originating at one or more devices.” See ¶ 0051. “For example, if time intervals between typed characters and/or typing inconsistencies increase at the same time as substantial and/or sudden forward and/or lateral acceleration and/or deceleration, this can further indicate that the user of a mobile device 105 is a driver. Being that for a driver to engage in a maneuver with sudden acceleration and/or deceleration the driver is expected to have temporarily stopped typing due to the increased attention a driver must pay to his driving activities, if such accelerations correlate closely with inconsistent typing speeds and/or slower typing speed and/or such accelerations are just prior to typing delays, this can be a strong indication that the user of mobile device 105 is a driver.” See ¶ 0098. Therefore, Abramson teaches to associate the manipulation, i.e. handheld state, of the mobile device to an identifying event during the driving trip.
It would have been obvious to one of ordinary skilled in the art at the time of invention to modify the combination of Bowne-Bryer and determine whether the driver’s mobile device 105 is in a handheld state by determining the orientation of the mobile device and accelerometer 145a data of the mobile device to automatically identify whether a user is a driver or a passenger so the passenger’s driver’s insurance premium does not affect due to the reckless driving of the driver, and therefore, not inadvertently affecting the insurance premium of other the passengers in the vehicle.
Consider claim 3, the method of claim 2, wherein:
the computing device is a mobile device, Bowne teaches, “a mobile device, such as a smartphone, is used to collect and transmit vehicle operation data” See ¶ 0008; and
detecting the driving event comprises detecting movement of the mobile device with respect to the reference frame of the vehicle indicative of a distracted driving event, Abramson teaches, “connected to and/or in communication with control circuit 140 are one or more sensors 145A-145M (generically sensors 145). Generally, sensors 145 are various components, devices, and/or receivers that are preferably incorporated within and/or in communication with mobile device 105. Sensors 145 preferably detect one or more stimuli, phenomena, or any other such inputs, as will be described in greater detail below. Examples of such sensors 145 include, but are not limited to, an accelerometer 145A, a gyroscope 145B, a GPS receiver 145C… mobile device 105 can preferably receive one or more inputs from one or more sensors 145 in order to determine an in-vehicle role of a user of mobile device 105.” See Abramson ¶ 0078. Abramson teaches, “various orientations and/or sudden changes perceived by gyroscope 145B (preferably, in certain scenarios, in combination with one or more inputs from various other sensors 145 such as accelerometer 145A, GPS 145C, and/or magnetometer 145E) can indicate that mobile device 105 is being operated in a handheld state by a user.” See ¶ 0135. Abramson teaches, “processor 110 [of the mobile device 105] executing one or more of software modules 130, including, preferably, determination module 170, computes one or more determination factor(s), based on the handheld state determination characteristic(s), such as a probability that that the handheld state of mobile device 105 is handheld, or that the handheld state of mobile device 105 is non-handheld. By way of example, based on a series of accelerometer 145A and gyroscope 145B inputs, the pattern of which indicates ongoing vibration and/or movement, it can be computed that there is a high probability (e.g., greater than 90%) that mobile device 105 is being operated in a handheld state. This is because a user of handheld mobile device 105--and particularly a driver who is further distracted by his/her driving responsibilities--is liable to produce far more vibration/shaking that is perceptible by mobile device 105” See Abramson ¶ 0136. Abramson teaches, “terms ‘handheld state’ and ‘handheld states’ as used herein are intended to encompass one or more states of a mobile device with respect to whether or not a user is in direct or indirect physical contact with the device. For example, the handheld state of a device in instances where a user holds the device in his/her hand, carries the device in his/her pocket, and/or balances the device on his/her knee can all be said to be ‘handheld.’ By way of further example, the handheld state of a device in instances where the device is positioned in a dock or cradle, and/or is otherwise not in direct or indirect contact with a user can be said to be ‘non-handheld.’” See ¶ 0061.Therefore, Abramson teaches a sensors (145a, etc.) within the mobile phone are being used to determine whether the user is distracted, based on the orientation of the phone and other sensor inputs.
Consider claim 4, the method of claim 2, wherein detecting the driving event comprises: determining a speed of the vehicle, Bowne teaches “mobile device 10 may collect certain driving data (e.g., driving behavior data and/or driving environment data) from sensors and/or devices external to mobile device 10 (e.g., speed sensors, blind spot information sensors, seat belt sensors, GPS device, etc.).” See ¶ 0048; and
detecting that the speed of the vehicle is indicative of a speeding event, Bowne teaches “an algorithm may compare acceleration data from accelerometer 54 (raw or filtered) to one or more predefined thresholds for notable acceleration, braking, or cornering” See ¶ 0072; Bryer teaches, “number of miles traveled above a predetermined speed threshold” Col. 2 line 43+. Abramson teaches, “an acceleration input that originates from an acceleration event (e.g., the speeding up or slowing down of a car) that is perceived by accelerometer 145A” See ¶ 0089.
Consider claim 5, the method of claim 2, wherein the driving event is a cornering event or an acceleration event, Bowne teaches “an algorithm may compare acceleration data from accelerometer 54 (raw or filtered) to one or more predefined thresholds for notable acceleration, braking, or cornering” See ¶ 0072.
Consider claim 6, the method of claim 1, further comprising:
retrieving, by the one or more processors, contextual data for the drive, Bowne teaches, “time stamping may allow for data from different sources (e.g., data from accelerometer 54, location tracking system 56, a seat belt sensor, etc.) to be synchronized for analyzing the different data together as a whole (e.g., to provide the driving context for a particular reading of accelerometer” See ¶ 0069; and
detecting, by the one or more processors, a correlation between the contextual data and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation, Bowne teaches, “an algorithm may compare acceleration data from accelerometer 54 (raw or filtered) to one or more predefined thresholds for notable acceleration, braking, or cornering. In some embodiments, data processing module 42 may analyze the acceleration data in combination with contextual data, which may provide a context for the acceleration data, and analyze the acceleration data based on the context data. Thus, for example, particular acceleration data may or may not indicate "notable acceleration" depending on the contextual data corresponding (e.g., based on time stamp data) to the particular acceleration data being analyzed. Data processing module 42 may utilize algorithms that analyze the acceleration data together with the relevant contextual data.” See ¶ 0080, Bowne teaches, “Contextual data may include, for example, location data and/or driving environment data. Module 42 may use location data (e.g., from location tracking system 56) in this context to determine, for example, the type of road the vehicle is travelling on, the speed limit, the location of the vehicle relative to intersections, traffic signs/light (e.g., stop signs, yield signs, traffic lights), school zones, railroad tracts, traffic density, or any other features or aspects accessible from location tracking system 56 that may influence driving behavior. Module 42 may use driving environment data (e.g., from environmental data applications 58) in this context to determine, for example, the relevant weather, traffic conditions, road conditions, etc.” See ¶ 0081. Abramson teaches, “[t]he terms ‘identifying event’ and ‘identifying events’ as used herein are intended to encompass one or more occurrences or instances of events, stimuli, or phenomena, including explicitly the perceived coordinated or correlated occurrence or instance of two or more such events, stimuli, and/or phenomena, such as those originating at one or more devices.” See ¶ 0051. “For example, if time intervals between typed characters and/or typing inconsistencies increase at the same time as substantial and/or sudden forward and/or lateral acceleration and/or deceleration, this can further indicate that the user of a mobile device 105 is a driver. Being that for a driver to engage in a maneuver with sudden acceleration and/or deceleration the driver is expected to have temporarily stopped typing due to the increased attention a driver must pay to his driving activities, if such accelerations correlate closely with inconsistent typing speeds and/or slower typing speed and/or such accelerations are just prior to typing delays, this can be a strong indication that the user of mobile device 105 is a driver.” See ¶ 0098.
Consider claim 7, the method of claim 6, wherein the contextual data comprises at least one of: weather data; a time of day of the drive, See ¶ 0072; location information, See ¶ 0072; map data, See ¶ 0072; or traffic data, Bowne teaches, “Contextual data may include, for example, location data and/or driving environment data. Module 42 may use location data (e.g., from location tracking system 56) in this context to determine, for example, the type of road the vehicle is travelling on, the speed limit, the location of the vehicle relative to intersections, traffic signs/light (e.g., stop signs, yield signs, traffic lights), school zones, railroad tracts, traffic density, or any other features or aspects accessible from location tracking system 56 that may influence driving behavior. Module 42 may use driving environment data (e.g., from environmental data applications 58) in this context to determine, for example, the relevant weather, traffic conditions, road conditions, etc.” See ¶ 0081
Consider claim 16, the computing device of claim 15, wherein the operations further include:
detecting, using the motion data and the acceleration vectors for the vehicle, a driving event that occurred prior to detecting the hard braking event, wherein the driving event is one of a distracted driving event, a speeding event, a cornering event, or an acceleration event; and
detecting a correlation between the driving event and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation, See rejection of claim 2.
Consider claim 17, the computing device of claim 15, wherein the operations further include:
retrieving contextual data for the drive, wherein the contextual data comprises at least one of:
weather data; a time of day of the drive; location information; map data; or traffic data; and
detecting a correlation between the contextual data and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation, See rejection of claims 6 and 7.
Consider claim 19, the one or more non-transitory computer-readable storage media of claim 18, wherein the operations further comprise: detecting, using the motion data and the acceleration vectors for the vehicle, a driving event that occurred prior to detecting the hard braking event, wherein the driving event is one of a distracted driving event, a speeding event, a cornering event, or an acceleration event; and detecting a correlation between the driving event and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation, See rejection of claim 2.
Consider claim 20, The one or more non-transitory computer-readable storage media of claim 18, wherein the operations further comprise:
retrieving contextual data for the drive, wherein the contextual data comprises at least one of:
weather data during the drive; a time of day of the drive; location information; map data; or traffic data; and
detecting a correlation between the contextual data and the hard braking event, wherein alerting the driver to the hard braking event is in further response to detecting the correlation, See rejection of claims 6 and 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Omer S. Khan whose telephone number is (571)270-5146. The examiner can normally be reached 10:00 am to 8:00 pm 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, Brian A. Zimmerman can be reached at 571-272-3059. 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.
/Omer S Khan/Primary Examiner, Art Unit 2686
Prosecution Insights