DETAILED ACTION
Response to Amendment
The amendment filed 4/9/26 has been accepted and entered. Accordingly, claims 1, 7, 12, and 17 are amended.
Response to Arguments
Applicant’s arguments with respect to the pending claims have been considered but are moot in view of the new grounds of rejection necessitated by applicant’s amendment.
Claim Rejections - 35 USC § 112
The rejection of claims 7 and 17 under 35 U.S.C. 112(b) as being indefinite has been withdrawn as a result of the amendment.
Claim Rejections - 35 USC § 112
The rejection of claims 7 and 17 under 35 U.S.C. 112(d) have been withdrawn as a result of the amendment.
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-2, 4-6, 8-13, 15-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 20230230484 to Al Faruque et al. (Far) in view of U.S. 20230035228 to Gupta et al. (Gupta) in view of US 20210078603 to Sarvedani et al. (Sar)
With respect to claims 1 and 12, Far discloses a system for personalized gap preference prediction of an ego vehicle driving on a road comprising:
one or more vision sensors operable to capture one or more images of a surrounding scene; and
(¶¶ 140 “image captured by the on-board camera at time n”; 145; 191; 20 extract scene graphs from camera data; 21 camera data . . . AV perception architectures utilizing sensor fusion”; FIG. 17; Fig. 8-9; 78; 124; 145; 204; abstract “present invention is directed to a Spatiotemporal scene-graph embedding methodology that models scene-graphs and resolves safety-focused tasks for autonomous vehicles . . . accepting the one or more images, extracting one or more objects from each image . . . generating a scene-graph for each image”)
one or more processors operable to:
generate a scene graph based on the captured images;
generate a scene embedding based on the scene graph;
generate vehicle data embedding based on vehicle data of the ego vehicle;
concatenate the scene embedding and the vehicle data embedding to generate a time-stamped state;
(¶¶ 19-28 “present invention to provide systems and methods that allow for Spatiotemporal scene-graph embedding to model scene-graphs and resolve safety-focused tasks for autonomous vehicles . . . a tool for systematically extracting and embedding road scene-graphs . . . quickly and easily extract scene graphs from camera data . . . user-friendly scene-graph extraction framework; allowing researchers to explore various spatio-temporal graph embedding methods . . . condensing the one or more scene-graphs into a spatial graph embedding, generating a spatia-temporal graph embedding from the spatial graph embedding, and calculating a confidence value for whether or not a collision will occur. The system may further comprise a risk assessment module for processing the spatio-temporal graph embedding through a temporal attention layer of the LSTM network to generate a context vector, processing the context vector through an LSTM decoder to generate a final spatio-temporal graph embedding, and calculating a confidence value for whether or not the one or more images contain a risky driving maneuver”; 100-105 temporal model of the present invention uses an LSTM for converting the sequence of scene-graph embeddings h, to the combined spatia-temporal embedding Z. For each timestamp t, the LSTM updates the hidden state p.sub.t and cell state c, as follows, p , c =ISTM; 140; 144-145)
In addition, Far at least suggests generating a preferred gap related to surrounding vehicles via the time stamped mlm cited above
(FIG. 10 “proximity thresholds” defines the set of enabled distance relations and their thresholds in feet; 80 assessing the risk of driving behaviors, traffic participants' relations that are considered to be useful are the distance relations and the directional relations. The assumption made here is that the local proximity and positional information of one object will influence the other's motion only if they are within a certain distance. Therefore, only the location information is extracted for each object and a simple rule is adopted to determine the relations between the objects using their attributes (e.g., relative location to the ego car), as shown in FIG. 4. For distance relations, two objects are assumed to be related by one of the relations r e {Near Collision (4 ft.), Super Near (7 ft.), Very Near (10 ft.), Near (16 ft.), Visible (25 ft.)} if the objects are physically separated by a distance that is within that relation's threshold; 148; 24 intervehicle distance determines confidence of risky behavior/ collision; 69)
However, Far fails to explicitly disclose the gap is a preferred gap, i.e., as described in the specification, a user preferred gap such that the ego vehicle operates to keep a gap from the corresponding surrounding vehicle at the preferred gap.
Gupta, from the same field of endeavor, discloses generating a preferred gap related to one of one or more surrounding vehicles at least in part by inputting a spatiotemporal state into a machine learning model and operates an ego vehicle to keep a gap from the corresponding surrounding vehicle at the preferred gap.
(i.e., FIG. 1 time gap between surrounding vehicle 104 relative to ego vehicle 102 input to machine learning model 116 with historical context data 114 to create a preferred gap to keep gap from the corresponding surrounding vehicle at the preferred gap at trip (n+1) wherein the mlm is used 302 to control the vehicle 304 “ego vehicle control” to result in 310, “actual distance between vehicles” as shown in FIG. 3 and corresponding descriptions; ¶¶ 27 As the ego vehicle 102 continues to do more trips, the ego vehicle 102 continues to calculate new parameters (e.g., gap preference, acceleration profile) through incremental learning and an updated STP ML model representing the parameters is uploaded to the cloud server 106. The cloud server 106 may update its aggregated STP ML model if there is a change from new data; 34 STP model module 207 outputs a target driving parameter, such as a target acceleration or a target gap between the ego vehicle and the lead vehicle; 52 update a cloud STP ML model associated with the driver of the ego vehicle 102 based on the initial STP ML model and the updated STP ML model to improve accuracy of personalized parameters for the driver of the ego vehicle 102. The historical data storage 114 of the cloud server 106 may store historical data related to the initial STP ML model and the updated STP ML model . . . cloud server 106 may guide the ego vehicle 102 of what the gap preferences, the acceleration profile to use in new situations by transmitting parameters based on the global STP ML model.; 53-54 personalized parameters for the vehicle may include a desired acceleration, a desired gap, and the like. In some embodiments, the personalized parameters for the ego vehicle 102 may be parameters for the STP ML model of the ego vehicle 102 such that the STP ML model of the ego vehicle 102 is updated. The parameters for the ego vehicle 102 may be used as guidance for the ego vehicle 102 . . . then the ego vehicle 102 may update the personalized time gap to be longer when driving under similar conditions. The ego vehicle 102 may update personalized parameters or the updated STP ML model to the cloud server 106. The updating process may repeat as the ego vehicle 102 continues to travel.; claims 1-8 personalized driving setting for the driver is a personalized adaptive cruise control setting for the driver . . . update the personalized driving setting based on driving preferences by the driver . . . controller is configured to determine a target gap between the vehicle and a leading vehicle based on the personalized driving setting, a current gap between the vehicle and the leading vehicle, and a relative velocity between the vehicle and the leading vehicle; claim 9 operate the vehicle based on the personalized driving setting)
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of effective filing date for the machine learning model of Far to generate a preferred gap related to a surrounding vehicle by operating the vehicle to keep the preferred gap output from the machine learning model, as taught by Gupta, in order to improve the automatic cruise control so that it is personalized for a particular driver and used more effectively since ACC’s which do not know the personal preferences of the user will be shut off by manual user intervention, personalization reduces ACC shut-off (Gupta, ¶ 19, 21).
In addition, although Far in view of Gupta disclose one or more sensors operable to capture vehicle data of the ego vehicle wherein the generated vehicle data is obtained by one or more sensors (i.e., Far, claim 1, accept images . . . extracting the one or more objects and the ego object from the one or more images as an object dataset for each image . . . scene graph extraction . . . bounding box for each object . . . BEV . . . proximity relation between the ego object and each object of the object dataset for each image by measuring a distance between the ego-object and each object . . . directional relation . . . scene graph; ¶¶ 24, 66 extract other vehicle objects and ego objects from images; 67-71), Far fails to explicitly disclose that vehicle data is captured using a different sensor than the vision sensor used to capture images of a surrounding scene.
Sar, from the same field of endeavor, also discloses determining the position of an ego vehicle relative to other vehicles in the surrounding environment using sensor data to ensure that the ego vehicle incorporates vehicle safety buffers or gaps relative other road users thereby enhancing safety and reducing the risk of sudden braking, acceleration and collisions (Sar, ¶¶ 25-26, cf. Spec. ¶ 14; 32 “minimum distance thresholds associated with the minimum distance between the ego vehicle 102 and the surrounding vehicles”; FIG. 5) wherein Sar similarly teaches using a camera to track surrounding vehicles (i.e., ¶43) but further teaches using a different sensor than the vision sensor for the surrounding scene for capturing vehicle data of the ego vehicle used to generate the preferred gap (minimum distance), i.e., dynamic data sensors 112 (¶¶, 40-41 position, heading, speed sensors of ego vehicle, determine current vehicle state, real time dynamic performance of ego vehicle, used in kinematics model 205; 57; compare FIG. 2 (i.e., ego vehicle 102 dynamic data branch from ego vehicle dynamic sensors and surrounding vehicle state data branch from camera input to 108 for issuing control parameters 212 that satisfy the gap/ minimum distance) with instant application Fig. 4; 66, 69-73; 75; claims 1-2 and 6)
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of effective filing date to use additional sensors to track the vehicle state of the ego vehicle, in order to improve predictions of future relative positioning and interactive motions between the ego vehicle and surrounding vehicles, thereby improving safety and reducing undesired traffic consequences (Sar, ¶¶ 3, 25, 32).
With respect to claims 2 and 13, Far in view of Gupta in view of Sar disclose the one or more processors are operable to extract visual information of the one or more surrounding vehicles and the road; and generate the scene graph based on the extracted visual information
(Far, ¶¶ 140 “image captured by the on-board camera at time n”; 145; 191; 20 extract scene graphs from camera data; 21 camera data . . . AV perception architectures utilizing sensor fusion”; FIG. 17; Fig. 8-9; 78; 124; 145; 204; abstract “accepting the one or more images, extracting one or more objects from each image . . . calculating relations between each object for each image, and generating a scene-graph for each image based on the aforementioned calculations. The system may further comprise instructions for calculating a confidence value for whether or not a collision will occur through the generation of a spatio-temporal graph embedding based on a spatial graph embedding and a temporal model”)
With respect to claims 4 and 15, Far in view of Gupta in view of Sar disclose the scene graph comprises:
an ego vehicle node corresponding to the ego vehicle, one or more surrounding vehicle nodes corresponding to the surrounding vehicles and edges between the ego vehicle node and the one or more surrounding vehicle nodes.
(Far, FIG. 2, FIG. 3 depicting scene graph with ego vehicle / surrounding vehicle nodes; Fig. 4, 8 and respective corresponding descriptions; ¶¶ 79 The nodes of a scene-graph, denoted as 0, represent the objects in a scene such as lanes, roads, traffic signs, vehicles, pedestrians, etc. The edges of a scene-graph are represented by the corresponding adjacency matrix A,, where each value in A, represents the type of the edges. The edges between two nodes represent the different kinds of relations between them (e.g., near, Front Left, isln, etc.); 23, 72 Each scene-graph may comprise one or more nodes representing the corresponding ego-object and the corresponding object dataset).
With respect to claims 5-6 and 16, Far in view of Gupta in view of Sar disclose the edges are vectors based on relative directions and distances between the ego vehicle and the one or more surrounding vehicles and a weight of each edge is a function of Euclidean distance between the ego vehicle and the corresponding vehicle
(Far, i.e., distance between ego vehicle and corresponding vehicle is a straight line Euclidean distance, ¶ 67 BEV representation includes “identifying a proximity relation between the ego-object and each object of the object dataset for each image by measuring a distance between the ego object and each object . . . directional relation . . . relative orientation . . . right lane middle lane left lane”, as distinguished from “horizontal displacement” also measured . . . generating a scene-graph for each image based on the BEV representation”; i.e., objects can be surrounding cars, Car_0, Car_1, FIG. 4; 79 collecting the list of objects in each image and their attributes, the corresponding scene-graphs are constructed . . . multiple types of edges connect nodes. The nodes of a scene-graph, denoted as 0, represent the objects . . . vehicles . . . edges of a scene-graph are represented by the corresponding adjacency matrix A, where each value in A, represents the type of the edges. The edges between two nodes represent the different kinds of relations between them (e.g., near, Front Left, isln, etc.)”, i.e., including Euclidean distance as discussed above)
(Far, ¶ 123 “Each node is assigned its type label from the set of actor names and its corresponding attributes (e.g., position, angle, velocity, current lane, light status, etc.) for relation extraction. Once all nodes are added to the scene-graph, the present invention extracts relations between each pair of objects in the scene.”; 148 extraction pipeline identifies three kinds of pairwise relations: proximity relations (e.g. visible, near, very near, etc.), directional (e.g. Front Left, Rear Right, etc.) relations, and belonging (e.g. car 1 is in left lane) relations. Two objects are assigned the proximity relation, r {Near Collision (4 ft.), Super Near (7 ft.), Very Near (10 ft.), Near (16 ft.), Visible (25 ft.)} provided the objects are physically separated by a distance that is within that relation's threshold. The directional relation, r e {Front Left, Left Front, Left Rear, Rear Left, Rear Right, Right Rear, Right Front, Front Right}, is assigned to a pair of objects . . . each vehicle's horizontal displacement is used relative to the ego vehicle to assign vehicles to either the Left Lane, Middle Lane, or Right Lane using the known lane width. The abstraction only considers three-lane areas, and, as such, vehicles in all left lanes and all right lanes are mapped to the same Left Lane node and Right Lane node respectively. If a vehicle overlaps two lanes (i.e., during a lane change), it is mapped to both lanes; claim 1 “ E. identifying a proximity relation between the ego-object and each object of the object dataset for each image by measuring a distance between the ego-object and each object; F. identifying a directional relation between the ego-object and each object of the object dataset for each image by determining a relative orientation of the ego-object and each object; and G. generating a scene-graph for each image based on the BEV representation”)
With respect to claims 8-9 and 18, Far in view of Gupta in view of Sar disclose the machine learning model is a temporal encoder wherein the one or more processors are further operable to:
obtain multiple time-stamped states in sequential time stamps based on images of the surrounding scene captured at different times and driving data obtained at the different times; and
input the multiple time-stamped states in sequential time stamps to the temporal encoder to generate the preferred gap.
(Far, i.e., FIG. 2 “generating a spatio-temporal graph”; FIG. 10 “temporal attention”, “sequence classification”; ¶¶ 19-28 “Spatiotemporal scene-graph embedding to model scene-graphs and resolve safety-focused tasks for autonomous vehicles . . . a tool for systematically extracting and embedding road scene-graphs . . . quickly and easily extract scene graphs from camera data . . . user-friendly scene-graph extraction framework; allowing researchers to explore various spatio-temporal graph embedding methods . . . condensing the one or more scene-graphs into a spatial graph embedding, generating a spatio-temporal graph embedding from the spatial graph embedding, and calculating a confidence value for whether or not a collision will occur. The system may further comprise a risk assessment module for processing the spatio-temporal graph embedding through a temporal attention layer of the LSTM network to generate a context vector, processing the context vector through an LSTM decoder to generate a final spatio-temporal graph embedding, and calculating a confidence value for whether or not the one or more images contain a risky driving maneuver”; 100-105 temporal model of the present invention uses an LSTM for converting the sequence of scene-graph embeddings h, to the combined spatio-temporal embedding Z. For each timestamp t, the LSTM updates the hidden state p.sub.t and cell state c, as follows, p , c =ISTM; 140; 144-145)
(Gupta, i.e., FIG. 1 time gap between surrounding vehicle 104 relative to ego vehicle 102 input to machine learning model 116 with historical context data 114 to create a preferred gap to keep gap from the corresponding surrounding vehicle at the preferred gap at trip (n+1) wherein the mlm is used 302 to control the vehicle 304 “ego vehicle control” to result in 310, “actual distance between vehicles” as shown in FIG. 3 and corresponding descriptions; ¶¶ 27 As the ego vehicle 102 continues to do more trips, the ego vehicle 102 continues to calculate new parameters (e.g., gap preference, acceleration profile) through incremental learning and an updated STP ML model representing the parameters is uploaded to the cloud server 106. The cloud server 106 may update its aggregated STP ML model if there is a change from new data; 34 STP model module 207 outputs a target driving parameter, such as a target acceleration or a target gap between the ego vehicle and the lead vehicle; 52 update a cloud STP ML model associated with the driver of the ego vehicle 102 based on the initial STP ML model and the updated STP ML model to improve accuracy of personalized parameters for the driver of the ego vehicle 102. The historical data storage 114 of the cloud server 106 may store historical data related to the initial STP ML model and the updated STP ML model . . . cloud server 106 may guide the ego vehicle 102 of what the gap preferences, the acceleration profile to use in new situations by transmitting parameters based on the global STP ML model.; 53-54 personalized parameters for the vehicle may include a desired acceleration, a desired gap, and the like. In some embodiments, the personalized parameters for the ego vehicle 102 may be parameters for the STP ML model of the ego vehicle 102 such that the STP ML model of the ego vehicle 102 is updated. The parameters for the ego vehicle 102 may be used as guidance for the ego vehicle 102 . . . then the ego vehicle 102 may update the personalized time gap to be longer when driving under similar conditions. The ego vehicle 102 may update personalized parameters or the updated STP ML model to the cloud server 106. The updating process may repeat as the ego vehicle 102 continues to travel.; claims 1-8 personalized driving setting for the driver is a personalized adaptive cruise control setting for the driver . . . update the personalized driving setting based on driving preferences by the driver . . . controller is configured to determine a target gap between the vehicle and a leading vehicle based on the personalized driving setting, a current gap between the vehicle and the leading vehicle, and a relative velocity between the vehicle and the leading vehicle; claim 9 operate the vehicle based on the personalized driving setting)
With respect to claims 10 and 19, Far in view of Gupta in view of Sar disclose the surrounding vehicles are a lead vehicle, a rear vehicle, one or more adjacent-lane vehicles, or a combination thereof
(Far, FIG. 3 “car-1” – “car-4”; FIG. 4, car_0, Car_1 shown relative to surrounding lanes; Fig. 8-10)
With respect to claims 11 and 20, Far in view of Gupta in view of Sar disclose the one or more vision sensors comprise one or more front-view vision sensors, one or more rearview vision sensors, one or more side-view vision sensors, or a combination thereof.
(Far, ¶191 on-board dashboard cameras; FIG. 4 and 9 depicting front view vision sensor capture)
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 20230230484 to Al Faruque et al. (Far) in view of U.S. 20230035228 to Gupta et al. (Gupta) in view of Sar and further in view of US 20230177850 to Ambrus et al. (Ambrus)
With respect to claims 3 and 14, Far in view of Gupta in view of Sar disclose wherein one or more processors are operable to:
detect the one or more surrounding vehicles from the captured images using an object detection module;
(Far, ¶¶ 140 “image captured by the on-board camera at time n”; 145; 191; 20 extract scene graphs from camera data; 21 camera data . . . AV perception architectures utilizing sensor fusion”; FIG. 17; Fig. 8-9; 78; 124; 145; 204; abstract “present invention is directed to a Spatiotemporal scene-graph embedding methodology that models scene-graphs and resolves safety-focused tasks for autonomous vehicles . . . accepting the one or more images, extracting one or more objects from each image . . . generating a scene-graph for each image”);
(Sar, claims 1-2 and 6)
generate lane masks using a lane segmentation module, and
(Far, ¶¶ 11 lane data extracted from image; 17; 67; 70; 77; 79; 81; 121-124; 147-148; claim 7)
the visual information comprises the detected one or more surrounding vehicles, the depth map, and the lane masks.
(Far, ¶¶ 11 lane data extracted from image; 17; 67; 70; 77; 79; 81; 121-124; 147-148; claim 7; FIG. 8 object detection detects objects including the surrounding vehicles and lane masks as visual information;
Far fails to disclose generating a depth map of the one or more surrounding vehicles using a monocular depth perception module such that visual information comprises the depth map.
Ambrus, from the same field of endeavor, discloses generating a depth map of the one or more surrounding vehicles using a monocular depth perception module such that visual information comprises the depth map
(i.e., 404, 416, FIG. 4; FIG. 6-10 and corresponding descriptions, i.e., 1002 “depth map of a monocular image”; abstract, ¶¶ 6-8, 55-58, 61, 76-80, 82-92, claims 1-12)
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of effective filing date to generate depth or three dimensional information from images as taught by Ambrus in the system of Far in view of Gupta in order to provide a low cost dimensional image extraction technique using an inexpensive camera/ sensing system to reduce cost (Ambrus, ¶¶ 1-5, 24-27), i.e., relative to other more expensive methods of extracting depth data, i.e., Lidar.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 20230230484 to Al Faruque et al. (Far) in view of U.S. 20230035228 to Gupta et al. (Gupta) in view of Sar and further in view of US 12158762 to O’hara et al. (Ohara)
With respect to claims 7 and 17, Far in view of Gupta in view of Sar disclose fail to explicitly disclose generating a natural language description of the scene based on the scene graph, wherein the natural language description comprises one or more sentences in natural language and feeding the natural language description to a natural language processing model to generate the scene embedding.
Ohara, from the same field of endeavor, discloses generating a natural language description of a scene captured by a camera at a vehicle wherein the natural language description comprises one or more sentences in natural language and feeding the natural language description to a natural language processing model to generate a scene embedding
(i.e., vehicle 100, Fig. 1 captures surrounding scene via camera 138 and generates a natural language description of the scene via visual language model 190 and corresponding descriptions; col. 14, ll. 1-20 natural language description of a scene, i.e., “lane ends ahead right”; col. 12, ll. 50-55 “identify a text embedding that maps/corresponds to the image embedding IE_X”; col. 13, ll. 1-13 “ if image X captures a vehicle catching a fire, the output of the text decoder 295 (in processing the image embedding IE_X determined from image X) can correspond to (or be used to generate) text string X, e.g., “a picture of a vehicle catching fire”. In this non-limiting example, the configuration file 12 can list a plurality of objects or events, including, for example, fire, stray animal, person, traffic cone, etc. Searching the configuration file 12 based on the text string X (“a picture of a vehicle catching fire”) can result in a match between the text string X (“a picture of a vehicle catching fire”) and the object or event of “fire”. In this case, the vehicle can be controlled based on the text string X.”; FIG. 4-5 and corresponding description)
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of effective filing date to implement the natural language generation for scene embedding as taught by Ohara, in the system of Far in view of Gupta in view of Sar in order to provide the additional benefit of translating situations in the surrounding environment into natural language in order to provide communication with a user, or anyone else monitoring, in communication with or driving the autonomous vehicle (Ohara, col. 17, ll. 37-60).
Previously Cited Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. 20230252795 to Tong is cited to disclose the subject matter of claims 7 and 17, as best understood, in Fig. 2-7 and corresponding description.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH J MALKOWSKI whose telephone number is (313)446-4854. The examiner can normally be reached 8:00 AM - 5:00 PM.
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, Faris Almatrahi can be reached at 313-446-4821. 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.
/KENNETH J MALKOWSKI/Primary Examiner, Art Unit 3667
Prosecution Insights