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 .
Remarks and Response to Arguments
This non-final office action is a response to the RCE filed on 12/15/2025. Claims 1-5, 7-19, and 21-22 are pending. Claims 1, 12, and 15 have been amended. Claims 6, 20, and 23 have been canceled.
Any arguments are moot due to the amendments to the claims.
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-5, 9, and 11-19 are rejected by 35 U.S.C 103 as being unpatentable over Rothenberg et. al. (US 20190100135 A1) and Ono et. al. (US 20170278391 A1).
Regarding Claim 1, Rothenberg discloses:
A system comprising: at least one processor; and a non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations comprising: (See at least ¶0025 via "The memory 130 stores information accessible by the one or more processors 120, including instructions 134 and data 132 that may be executed or otherwise used by the processor 120")
obtaining data associated with a current trajectory of an autonomous vehicle, (See at least ¶0036 via "navigation system 168 may be used by planner system 102 in order to determine and follow a route to a location")
at least one constraint, (See at least ¶0039 via "The perception system 172 also includes one or more components for detecting objects external to the vehicle such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc")
executing a model that characterizes actions of autonomous vehicles to determine, in real-time and based on the current trajectory, the data associated with (See at least ¶0028 via "If an event meets one of these acceleration thresholds, a notification may be generated" and ¶0029 via "As more feedback is received, machine learning can be used, for instance, to train a model for determining whether a notification is required" and ¶0023 via "Because these notifications are happening in real time, they can provide a sense of reassurance and safety to the passenger thereby reducing any discomfort caused by sudden accelerations". Additionally, see at least ¶0050 wherein the change of acceleration is input into the model to determine if a notification should be generated in real-time.)
analyzing the current trajectory, the at least one constraint, and the (See at least ¶0028 via "If an event meets one of these acceleration thresholds, a notification may be generated. In this regard, very high changes in acceleration (positive or negative) for very brief periods of time, high changes in acceleration for longer periods, as well as some patterns of changes in acceleration may trigger the generation of a notification" & also ¶0052 via " In some instances, in addition to the instructions, the messages may contain additional information which identifies a reason why the vehicle took a particular action. For example, if a message includes instructions for accelerating the vehicle, the message may also include additional information identifying an object in the vehicle's environment that cause the vehicle to need to accelerate according to the instructions.")
generating, in response to the determination of the reason, a notification that includes the reason, (See at least ¶0052 via "information identifying an object in the vehicle's environment that cause the vehicle to need to accelerate" which the acceleration triggers the notification that has an intensity via ¶0019 via "the thresholds used may affect the number and frequency of notifications, therefore there is a tradeoff between providing the notifications to ensure the passenger that the vehicle is operating properly and providing too many notifications which can be disturbing, uncomfortable, or even annoying to passengers" and ¶0059 via "In some instance, the representation corresponding to the object that likely caused the acceleration event may be flagged or highlighted. As an example, the representation 1020 may appear to glow or change color (e.g. from blue to red or green to red, etc.) during the time that the notification is displayed on the display").
However, although Rothenberg discloses generating a notification including the reason for an unanticipated vehicle action, Rothenberg does not explicitly disclose the data associated with the driving history, the data associated with the context, the specific timestamp, or the intensity of the notification being based on a deviation.
Nevertheless, Ono--who is in the same field of endeavor--discloses: data associated with a driving history of a user of the autonomous vehicle from an expectation database, (See at least ¶0207 via "A movement history of the assisted vehicle 24 is recorded in the driver information database 70. The movement history includes a history regarding the vehicle position and time when the vehicle is running. Moreover, a system operation history is recorded in the driver information database 70. The system operation history includes information such as contents, date and time of the notification regarding the impediment event and the avoidance control that have been provided to the assisted vehicle 24. Furthermore, information of driver characteristics is recorded in the driver information database 70. The driver characteristics include information such as the various settings and requests from the driver of the assisted vehicle 24 and the driving skill of the driver." as well as ¶0208 via "The information of the movement history recorded in the driver information database 70 is supplied to a visit frequency determination unit 72. …The visit frequency determination unit 72 extracts, from the impediment event, an event that corresponds to the unexpected event for the driver because a frequency of visit by the driver to the location of occurrence of the event is low." **Wherein the driving history stored in the database is used to determine expected/unexpected status)
and data associated with a context that represents a discrepancy between current data values and expected data values; (See at least ¶0086 via " the “unexpected event” refers to the impediment event whose frequency of encounter by the driver is equal to or less than a certain level" and ¶0087 via " a frequency of visit by the driver to a location of occurrence of the impediment event is equal to or lower than a certain level, and accordingly the frequency of encounter with the impediment event is low" and ¶0096 via "The regular event is a daily event for a driver whose living area includes a location of occurrence of the regular event. Therefore, in a case where the target of assistance is the driver within the living area, it is reasonable to treat the regular event as the expected event" **Wherein the history of encountering an event establishes whether or not an event is expected, and if the event probability is low relative to the expectation, then the event is unexpected. Thus, the current event frequency/probability (familiarity) compared to the historical frequency illustrates a discrepancy between current and expected values.)
action at an associated timestamp; (See at least ¶0188 via " In the center 44, statistical processing with regard to the time of occurrence of the impediment event is performed based on the large amount of data accumulated." **Wherein the time of occurrence (timestamp) is used to help determine if the event is an unexpected event)
wherein an intensity of the notification is based on, at least in part, a deviation from expectations of a user determined from data associated with the driving history from the expectation database (See at least ¶0157 via "The certainty level calculated by the event information calculation unit 74 is provided to a notification decision unit 60…Based on the certainly level of the event, the notification decision unit 60 performs a notify/not-notify process that is a final judgment on whether or not to execute notifying." as well as ¶0159 via " In the HMI specification determination process, whether to adopt the straightforward notification or the euphemistic notification is determined based on the certainty level of the impediment event. More specifically, if the certainty level is sufficiently high, then the straightforward notification is selected as the method of notifying. On the other hand, if the certainty level is not yet high enough, the euphemistic notification is selected as the method of notifying." as well as ¶0204 via "the frequency of occurrence, the probability of occurrence, and the stress level of the impediment event correspond to the “notification necessity level”" **Wherein once an event is classified as unexpected, the system computes the probability of occurrence/certainty level of the event; if the system is more certain of the event's occurrence (higher certainty level) then the system outputs a straightforward notification - For example see ¶0115-¶0116 via "(Example) “There is xx about ∘∘ meters down this road”". Furthermore, if the certainty level is lower, the system outputs a euphemistic notification - For example, see ¶0117-¶0118. The straightfoward and euphemistic notification types correspond to the different intensities of the notification, which are based on the deviation from expectations (the unexpected event, which is determined based on a users frequency of encountering the event/location)).
Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the given invention to modify Rothenberg's unexpected vehicle action notification system in view of the concepts of considering a user's driving history, a discrepancy between current and expected data, time stamp, and notification intensity such as disclosed by Ono in order to solve the issue of detecting conditions that may be unexpected to a vehicle user and adjusting notifications based on such. Rothenberg's unexpected vehicle acceleration is triggered by an environmental object, so, unexpected environmental conditions/events informs unexpected vehicle maneuvers. Therefore, although Ono's events are related to external events rather than Rothenberg's own vehicle events, one of ordinary skill in the art would recognize that if an environmental event is unexpected, a reactive vehicle maneuver would also be unexpected. Thus, it would have been obvious to incorporate Ono's classification of unexpected events based on frequency of occurrence/movement history in order to provide helpful notifications to the driver whilst maintaining the trust of the driver/user: "provide the driver of the assisted vehicle 24 with the notification useful for continuing safety driving of the assisted vehicle 24, without annoying the driver." [Ono ¶0198]; "if misinformation occurs frequently, the driver trusts the notification less and finds the notification more annoying…if the notification is not provided until sufficient certainly level is obtained from a viewpoint of emphasizing reliability of the notification, the driver is more likely to encounter the impediment event without receiving the notification" [Ono ¶0016].
Regarding Claim 2, Rothenberg in view of Sorci and Newton disclose the system of Claim 1.
Furthermore, Rothenberg discloses: wherein the model is a machine learning model trained to output unanticipated autonomous vehicle actions (See at least ¶0029 via "As more feedback is received, machine learning can be used, for instance, to train a model for determining whether a notification is required" and "a classifier can be trained to use acceleration changes and information to determine if a certain discomfort metric or acceleration threshold has been met, such that a notification should be generated").
Regarding Claim 3, Modified Rothenberg discloses the system of Claim 1.
Furthermore, Rothenberg discloses: wherein the at least one constraint comprises at least one object within a predetermined range of the autonomous vehicle (See at least ¶0003 via " the method also includes identifying a relative area around the vehicle corresponding to a location of the object, and generating the notification is further based on the relative area such that the notification identifies the relative area" and ¶0055 via "For instance, the determined object's location may be used to identify a relative area around the vehicle such as “front”, “rear”, “left”, “right”, or any combination of these relative to the direction of the vehicle").
Regarding Claim 4, Modified Rothenberg discloses the system of Claim 3.
Furthermore, Rothenberg discloses: wherein the at least one object comprises a pedestrian or another vehicle located in the current trajectory of the autonomous vehicle (See at least ¶0039 via " The perception system 172 also includes one or more components for detecting objects external to the vehicle such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc").
Regarding Claim 5, Modified Rothenberg discloses the system of Claim 1.
Furthermore, Rothenberg discloses: wherein the data associated with the context comprises is obtained from one or more of a semantic map, localization data, or perception data (See at least ¶0040 via "Planner system 102 may use the positioning system 170 to determine the vehicle's location and perception system 172 to detect and respond to objects when needed in order to generate a short term plan for maneuvering the vehicle in order to reach the destination location safely" and ¶0042 via "Each of these radar, camera, and lasers devices may be associated with processing components which process data from these devices as part of the perception system 172 and provide sensor data to the planner system 102" and ¶0047).
Regarding Claim 9, Modified Rothenberg discloses the system of Claim 1.
Furthermore, Rothenberg discloses: wherein the notification output system is located within an interior of the autonomous vehicle, wherein the user is a passenger within the autonomous vehicle (See at least ¶0045 via "computing device 110 may generate and display notifications for certain acceleration events on an internal display, such as internal display 152, of the vehicle in real time in order to provide the passenger with a greater sense of understanding and safety while being driven to the destination").
Regarding Claim 11, Modified Rothenberg discloses the system of Claim 1.
Furthermore, Rothenberg discloses: wherein the notification output system is configured to output the notification (See at least ¶0045 via "computing device 110 may generate and display notifications for certain acceleration events on an internal display" and Fig. 11 block 1140).
Regarding Claim 12, Rothenberg discloses:
A non-transitory computer readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising: (See at least ¶0025 via "The memory 130 stores information accessible by the one or more processors 120, including instructions 134 and data 132 that may be executed or otherwise used by the processor 120")
(Regarding the instructions, see Claim 1 rejection because the steps are the same)
Regarding Claim 13, Modified Rothenberg discloses the non-transitory computer readable medium of Claim 12.
Furthermore, Rothenberg discloses: wherein the model is a machine learning model trained to output unanticipated autonomous vehicle actions (See at least ¶0029 via "As more feedback is received, machine learning can be used, for instance, to train a model for determining whether a notification is required" and "a classifier can be trained to use acceleration changes and information to determine if a certain discomfort metric or acceleration threshold has been met, such that a notification should be generated").
Regarding Claim 14, Modified Rothenberg discloses the non-transitory computer readable medium of Claim 12.
Furthermore, Rothenberg discloses: wherein the at least one constraint comprises at least one object within a predetermined range of the autonomous vehicle (See at least ¶0003 via " the method also includes identifying a relative area around the vehicle corresponding to a location of the object, and generating the notification is further based on the relative area such that the notification identifies the relative area" and ¶0055 via "For instance, the determined object's location may be used to identify a relative area around the vehicle such as “front”, “rear”, “left”, “right”, or any combination of these relative to the direction of the vehicle").
Regarding Claim 15, Rothenberg discloses:
A method comprising: (Regarding the instructions, see Claim 1 rejection because the steps are the same).
Regarding Claim 16, Modified Rothenberg discloses the method of Claim 15.
Furthermore, Rothenberg discloses: The method of claim 15, wherein the model is a machine learning model trained to output unanticipated autonomous vehicle actions (See at least ¶0029 via "As more feedback is received, machine learning can be used, for instance, to train a model for determining whether a notification is required" and "a classifier can be trained to use acceleration changes and information to determine if a certain discomfort metric or acceleration threshold has been met, such that a notification should be generated").
Regarding Claim 17, Modified Rothenberg discloses the method of Claim 15.
Furthermore, Rothenberg discloses: wherein the at least one constraint comprises at least one object within a predetermined range of the autonomous vehicle (See at least ¶0003 via " the method also includes identifying a relative area around the vehicle corresponding to a location of the object, and generating the notification is further based on the relative area such that the notification identifies the relative area" and ¶0055 via "For instance, the determined object's location may be used to identify a relative area around the vehicle such as “front”, “rear”, “left”, “right”, or any combination of these relative to the direction of the vehicle").
Regarding Claim 18, Modified Rothenberg discloses the method of Claim 17.
Furthermore, Rothenberg discloses: wherein the at least one object comprises a pedestrian or another vehicle located in the current trajectory of the autonomous vehicle (See at least ¶0039 via " The perception system 172 also includes one or more components for detecting objects external to the vehicle such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc").
Regarding Claim 19, Modified Rothenberg discloses the method of Claim 15.
Furthermore, Rothenberg discloses: wherein the data associated with the context comprises is obtained from one or more of a semantic map, localization data, or perception data (See at least ¶0040 via "Planner system 102 may use the positioning system 170 to determine the vehicle's location and perception system 172 to detect and respond to objects when needed in order to generate a short term plan for maneuvering the vehicle in order to reach the destination location safely" and ¶0042 via "Each of these radar, camera, and lasers devices may be associated with processing components which process data from these devices as part of the perception system 172 and provide sensor data to the planner system 102" and ¶0047).
Claims 7-8 are Rejected by U.S.C 103 as being unpatentable over Rothenberg et. al. (US 20190100135 A1) and Ono et. al. (US 20170278391 A1) in view of Curtis et. al. (US 20170072850 A1).
Regarding Claim 7, Modified Rothenberg discloses the system of Claim 1.
However, Modified Rothenberg does not explicitly disclose, but Curtis discloses: wherein generating the notification comprises: obtaining data associated with a profile of the user, a notification history of the user, and notification preferences of the user; and ((See at least ¶0058 {profile of user} via "The user profile can include one or more modules (e.g., the algorithms used above; other algorithms, etc.) configured to determine a notification (e.g., based on the imminent driving event)"and ¶0056 {notification history of user} via "In a second variation, the notification parameters can be determined based on historic user notifications (e.g., all past notifications, past notifications for the specific imminent driving event, past notifications for the driving event class, etc.)" and ¶0059 {notification preferences of user} via "Notification preferences can include: notification event thresholds (e.g., the threshold probability of an imminent event, above which the user is notified), notification timing (e.g., when the notification should be presented, relative to predicted occurrence of the imminent driving event), notification types (e.g., audio, video, graphic, haptic, thermal, pressure, etc.), presentation parameters (e.g., volume, size, color, animation, display location, vibration speed, temperature, etc.), notification content (e.g., driving recommendation, vehicle instructions, video, virtual representation of physical world, command, warning, context-aware information presentation, personalized recommendations, reminders, etc.), notification device (e.g., smartphone, hub, smartwatch, tablet, vehicle display, vehicle speaker, etc.), or values (or value ranges) for any other suitable notification parameter")
generating the notification in accordance with the data associated with a profile of the user, the notification history, and the notification preferences (See at least ¶0054 via "The notification parameters can be learned, selected, or otherwise determined. The notification parameters for a given imminent driving event are preferably associated with and/or determined based on a user profile, but can be otherwise determined. In one variation, the notification parameters can be determined based on the user notification preferences, vehicle data, and external data"
Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the given invention to modify Modified Rothenberg in view of the utilization of data from a user profile, notification history, and notification preferences of a user when generating notifications from Curtis. This is because the user could customize the notifications to their own needs or desires, such as having a notification being received sooner or later, or setting different types of notifications (visual, haptic, etc.) (see Curtis ¶0028) which would improve comfort and the overall riding experience.
Regarding Claim 8, Modified Rothenberg disclose the system of Claim 7.
However, Modified Rothenberg does not explicitly disclose, but Curtis discloses: wherein the operations further comprise: receiving an input indicating a preference of the user for future notifications; (See at least ¶0025 via " The vehicle notification system can additionally function as a user input to the system" and ¶0057 via " Alternatively or additionally, the user attribute values can be received from the user (e.g., manually input), from a secondary user, extracted from secondary sources (e.g., from social networking system content feeds generated by or received by the user, from social networking system profiles, etc.), or otherwise determined")
updating the data indicating the notification preferences with the input; and generating notifications in accordance with the updated data indicating the notification preferences (See at least ¶0075 via "The user profile is preferably an updated user profile generated based on an initial user profile, but can alternately be a new user profile. The user profile can be generated and/or updated based on: the vehicle operation data sets, notification parameters, user response" and ¶0079 via "The method can additionally include generating an additional notification S300, which functions to utilize the updated user profile")
Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the given invention to modify Modified Rothenberg in view of the notification preferences of a user when generating notifications from Curtis. This is because the user could customize the notifications to their own needs or desires, such as having a notification being received sooner or later, or setting different types of notifications (visual, haptic, etc.) (see Curtis ¶0028) which would improve comfort and the overall riding experience.
Claim 10 is Rejected by U.S.C 103 as being unpatentable over Rothenberg et. al. (US 20190100135 A1) and Ono et. al. (US 20170278391 A1) in view of Urmson et. al. (US 8954252 B1).
Regarding Claim 10, Modified Rothenberg discloses the system of Claim 1.
However, Modified Rothenberg does not disclose the notification being output on the exterior of the vehicle. Nevertheless, Urmson--who is in the same field of endeavor--discloses: wherein the notification output system is located on an exterior of the autonomous vehicle (See at least Figure 6A, 6B, and 6C which show a notification output display on the exterior of the vehicle).
PNG
media_image1.png
798
526
media_image1.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the given invention to include an exterior notification display from Urmson to Modified Rothenberg in order to have better communication and safety measures with pedestrians. Additionally, this allows the vehicle to communicate that it recognizes/sees the pedestrian (Urmson Col 9. Line 25).
Claims 21-22 are Rejected by U.S.C 103 as being unpatentable over Rothenberg et. al. (US 20190100135 A1) and Ono et. al. (US 20170278391 A1) in view of Newton et. al. (US 20210331663 A1).
Regarding Claim 21, Modified Rothenberg discloses the system of Claim 1.
Furthermore, Ono discloses data associated with a context, but does not explicitly disclose the data being a deviation in current versus expected localization data.
Nevertheless, Newton—who is in the same field of endeavor—discloses: wherein the data associated with the context is a deviation in current localization data when compared to expected localization data (See at least ¶0048 via "The path interpreter unit 134 is configured to compare the driver's expected vehicle performance with the estimated actual vehicle performance and generate performance delta data that indicates the differences between the driver's expected vehicle performance and the estimated actual vehicle performance. For example the performance delta data may include: (1) difference between: driver expected roll, pitch, yaw and vehicle's current roll, pitch, yaw; (2) difference between: driver expected roll, pitch, yaw rates and vehicle's current roll, pitch, yaw rates; (3) difference between driver expected X, Y and Z velocities and vehicle's current X, Y and Z velocities; and (4) difference between driver expected X, Y and Z accelerations and vehicle's current X, Y and Z accelerations " *Wherein the current versus expected roll, pitch, yaw, and current versus expected X, Y, Z velocities and acceleration values that come from the sensors—odometry, IMU, etc—represent the systems current versus expected localized state).
Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the given invention to modify the system disclosed by Modified Rothenberg in view of incorporating Newton's data representing the discrepancy of expected versus current perceived data that is input into the ML model, in order to better determine when vehicle control signals are not aligning with the expected or intended performance, because having quantified discrepancy data fosters in improving the understanding of the nature of the unanticipated event and the ability to determine why the event occurred. Furthermore, Newton detects when an issue is arising and that the controls need to react in real time: "In at least some applications, the use of a vehicle control system that decouples actuators of the vehicle drivetrain system from the driver may enable the vehicle actuators to act at significantly higher speeds than that of a human reaction time allowing for actions to be taken for on-coming hazards before the driver even realizes there is an issue" [Newton ¶0019], which illustrates that a human might not understand the issue until after a vehicle reaction, which further justifies the data being included to ultimately determine if a notification should be provided to the human.
Regarding Claim 22, Modified Rothenberg discloses the system of Claim 1.
Furthermore, Ono discloses data associated with a context, but does not explicitly disclose the data being a deviation in current versus expected localization data.
Furthermore, Newton discloses: wherein the data associated with the context is a deviation in current perception data when compared to expected perception data (See at least ¶0048 via “ The path interpreter unit 134 is configured to compare the driver's expected vehicle performance with the estimated actual vehicle performance and generate performance delta data that indicates the differences between the driver's expected vehicle performance and the estimated actual vehicle performance. For example the performance delta data may include: (1) difference between: driver expected roll, pitch, yaw and vehicle's current roll, pitch, yaw; (2) difference between: driver expected roll, pitch, yaw rates and vehicle's current roll, pitch, yaw rates; (3) difference between driver expected X, Y and Z velocities and vehicle's current X, Y and Z velocities; and (4) difference between driver expected X, Y and Z accelerations and vehicle's current X, Y and Z accelerations.” And also ¶0030 via “In example embodiments, IMU 120 includes one or more accelerometers and directional sensors to measure the following real-time attributes about the pose and movement of vehicle 100: yaw position, pitch position, roll position, lateral velocity, longitudinal velocity, vertical velocity, lateral acceleration, longitudinal acceleration and vertical acceleration”)
Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the given invention to modify the system disclosed by Modified Rothenberg in view of incorporating Newton's data representing the discrepancy of expected versus current perceived data that is input into the ML model, in order to better determine when vehicle control signals are not aligning with the expected or intended performance, because having quantified discrepancy data fosters in improving the understanding of the nature of the unanticipated event and the ability to determine why the event occurred. Furthermore, Newton detects when an issue is arising and that the controls need to react in real time: "In at least some applications, the use of a vehicle control system that decouples actuators of the vehicle drivetrain system from the driver may enable the vehicle actuators to act at significantly higher speeds than that of a human reaction time allowing for actions to be taken for on-coming hazards before the driver even realizes there is an issue" [Newton ¶0019], which illustrates that a human might not understand the issue until after a vehicle reaction, which further justifies the data being included to ultimately determine if a notification should be provided to the human.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bijlani et. al. (US 20170028913 A1)
Kapuria et. al. (US 10745030 B2)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAYLA RENEE DOROS whose telephone number is (703)756-1415. The examiner can normally be reached Generally: M-F (8-5) 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, Abby Lin can be reached on (571) 270-3976. 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.
/K.R.D./Examiner, Art Unit 3657 /ABBY LIN/Supervisory Patent Examiner, Art Unit 3657