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 .
Status of Claims/ Election
This Office Action is in response to Amendments & Remarks filed on 02/15/2026 for application number 18/543,570 filed on 12/18/2023, in which claims 1-20 were originally presented for examination.
Applicant’s election without traverse of claims 1-7 & 17-20 in the reply filed on 10/23/2025 has been acknowledged, wherein claims 8-16 were not elected and cancelled by applicant from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Claims 1, 3, 17, 19, 23 & 25 are now amended, accordingly, claims 1-7 & 17-29 are currently pending.
Priority
Acknowledgment is made of applicant’s claim for (1) priority of provisional patent application No. 6,341,3226 filed on 10/04/2022, and (2) being CON of application No. 18/240,102 filed on 08/30/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/10/2023 has been received and considered.
Examiner Notes
Examiner cites particular paragraphs (or columns and lines) in the references as applied to Applicant’s claims for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. The prompt development of a clear issue requires that the replies of the Applicant meet the objections to and rejections of the claims. Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP §2163.06. Applicant is reminded that the Examiner is entitled to give the Broadest Reasonable Interpretation (BRI) to the language of the claims. Furthermore, the Examiner is not limited to Applicant’s definition which is not specifically set forth in the claims. See MPEP §2111.01.
Response to Arguments
Arguments filed on 02/15/2026 have been fully considered and are addressed as follows:
Regarding the Claim Objections: The claim objection(s) is/are withdrawn, as the amended Claim(s) 5 filed on 02/15/2026 has/have properly addressed the claim(s) informality objection(s) recited in the Non-Final Office Action mailed on 11/18/2025.
Regarding the Double Patenting: The non-statutory double patenting rejections are withdrawn, as filed Terminal Disclaimer on 02/15/2026 has been approved on 02/26/2026.
Regarding the prior art claim rejections under 35 USC §102(a)(1): Applicant’s Amendments/ Remarks regarding the rejections of claims under the prior arts in records are persuasive in view of the currently amended base claim(s) 1, 17 & 23. Accordingly, the previous prior art rejections under 35 USC §102(a)(1) have been withdrawn. However, applicant’s amendment necessitated the new ground of rejection under §103 presented below, which were necessitated by the applicant’s amendment.
For at least the foregoing reasons, and the rejections outlined below, the prior art rejections are maintained.
Claim Rejections - 35 USC §103
In the event the determination of the status of the application as subject to AIA 35 USC §102 and §103 (or as subject to pre-AIA 35 USC §102 and §103) is incorrect, any correction of the statutory basis 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 USC §103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 1-7 & 17-29 is/are rejected under 35 USC §103 as being unpatentable over PG Pub. No. US-2018/0091930-A1 by Jefferies, which is found in the IDS submitted on 01/22/2024 (hereinafter “Jefferies”) in view of PG Pub. No. US-2009/0302999-A1 by Skertic (hereinafter “Skertic”)
As per Claim 1, Jefferies discloses a vehicle management system (Jefferies, in at least Fig(s). 1 & 8 and ¶¶ 6-26, 87 & 206-243, discloses vehicle access and management system to manage a fleet of rental-carshare RCS vehicles) comprising:
a dongle device configured to communicate with a vehicle controller of a vehicle, the vehicle having a set of first vehicle states comprising a vehicle lock state, the vehicle controller operating to at least set the vehicle lock state to locked and unlocked (Jefferies, in at least Fig. 8 [reproduced here for convenience] and ¶¶6-26 & 74, discloses an external hub 700 that is configured to bridge the in-vehicle infotainment unit to the peripheral devices, wherein the external hub is easily installed by plugging it into an on-board diagnostic port (OBD) of the vehicle and providing a method of digitally controlling electromechanical functions of a vehicle door lock/unlock through the vehicle's CAN Bus network, wherein the infotainment unit has the ability to send digital commands for locking/unlocking doors, and the external hub is quickly installed through a variety of methods, such as plugged into an OBDII port that is present in most modern vehicles, wherein instructions and commands are wirelessly transmitted to the vehicle, which allows remote control of the various systems and functions of the vehicle. Jefferies, in at least Fig. 8 and ¶¶255-256, further discloses dongles, mailed to participants, who self-installed them by connecting the dongle to the vehicular on-board diagnostic port),
the dongle device coded to a vehicle VIN of the vehicle (Jefferies, in at least Fig(s). 13A-B & 24E and ¶¶177-188, discloses the In-Vehicle Applications (IVA) queries the vehicle ECU over the CAN bus in order to obtain the Vehicle Identification Number (VIN), wherein the VIN is stored in memory and used in order to determine the vehicle's identity, which then allows the appropriate codes to be determined depending on how the codes are stored. Jefferies further discloses the VIN is instead sent via the wireless network connection to the remote computing system, wherein the remote computing system then determines the correct codes to use by decoding the VIN to lookup in a database the correct command codes and/or executable instructions to transmit back to the IVA over the wireless network/Internet, wherein the codes are received by the IVA and stored in an appropriate table for lookup, access, and use to enable car commands such as unlocking the doors, etc. Jefferies also discloses the external hub connected to the OBD2 Port performs the same query for the VIN over the CAN bus, wherein once the VIN is obtained, the VIN then is stored in memory and/or compared to existing VIN s in memory);
PNG
media_image1.png
283
612
media_image1.png
Greyscale
Jefferies’s Fig. 8 (emphasis added)
an app configured to engage a user device of a first user, the user device configured to wirelessly communicate with the dongle device (Jefferies, in at least Fig. 1 [reproduced here for convenience] and ¶¶6-26 & 255, discloses the external hub provides a wireless connection between the in-vehicle infotainment unit and the backend, wherein the backend includes remote servers, cloud-based servers, and mobile applications running on mobile devices, which is wirelessly connected to the vehicle to allow for monitoring and configuring the vehicle, the provision of connected-vehicle services, and the remote issuing of commands to the various systems of the vehicle. Jefferies further discloses participants had to download a specialized smartphone application that allowed the phone to communicate with the dongle); and
a central database configured to store: i) a set of terms and conditions that must be satisfied for a user engagement with the vehicle, the user engagement comprising user access control to the vehicle (Jefferies, in at least Fig(s). 1, 13A-B & 29 and ¶¶6-26, 87, 131, 179, 184 & 211, discloses remote servers/ databases, wherein these servers contain, among other functionality, a vehicle database. Jefferies further discloses the remote computing devices or servers run application 112, the backend of the vehicle access and management system, and relevant data is stored in databases on Storage 114, wherein a remote computing system determines the correct codes to use by decoding the VIN to lookup, in a database, the correct command codes and/or executable instructions to transmit back to the In-Vehicle Applications (IVA) over the wireless network/Internet, wherein codes (e.g., command codes or executable instructions) are received by the IVA and use to enable car commands such as unlocking the doors. Jefferies also discloses, if the vehicle has been already identified, then the corresponding commands for that vehicle should also have been identified or saved, wherein, at block 1308, the appropriate commands are obtained from memory, where they are saved in a table or database, and the remote computing server(s) role(s) is/are to provide a central repository of vehicle control, and an associated database. Jefferies, in at least ¶¶ 228-229 & 234, further discloses the customer is able to accept terms and conditions required by the rental or car share service to use the car, be offered insurance with its own terms and conditions, etc.);
PNG
media_image2.png
489
502
media_image2.png
Greyscale
Jefferies’s Fig. 1
wherein:
when the dongle device is communicating with the vehicle controller and if the user satisfies the set of terms and conditions of the user access control to the vehicle, the app enables the user device to wirelessly communicate: i) with the dongle device to change the vehicle locked state from locked to unlocked (Jefferies, in at least Fig(s). 6A-B and ¶¶6-26, 78, 97, 167, 176 & 212-220, discloses the servers keep a number of tables, which contain associations between the cars, external hubs, customers, and others as required by a rental-carshare (RCS) operation, wherein these associations assist with authorization/control of car functionality, and authentication and authorization of the user where the user is authorized to control the car. Jefferies discloses the backend includes remote servers, cloud-based servers, and mobile applications running on mobile devices, which is wirelessly connected to the vehicle to allow for monitoring and configuring the vehicle, the provision of connected-vehicle services, and the remote issuing of commands to the various systems of the vehicle. Jefferies further discloses the remote server 1602 generates an access code to be sent to the mobile application for storage, along with all relevant reservation data, i.e., length of reservation, dates, times, destination, starting places, prices for all services, services included, etc., wherein the access code is then used to access the car in a variety of ways, e.g., the access code itself is transmitted from the remote servers 1602 to the vehicle. Then, if the access code is presented by the mobile device 206 to the IVA 1604/external hub, e.g. for example, using RFID/NFC with RFID Reader 302, and it corresponds to the access code on the IVA 1602 or external hub, commands will be sent to unlock all the doors and enable the starter. An example of the access code presented by the mobile device 206 corresponding to the code on the IVA 1602 or external hub includes the access codes matching, wherein the temporary access code is instead sent from the mobile device 206 to the remote servers 1602. If the access code corresponds to the access code that the remote servers 1602 have associated with an active reservation, the remote servers 1602 will send a command to the vehicle to unlock the doors for the customer and enable the starter).
Jefferies is silent on that its discloses central database configured to store a time stamp one value when the vehicle lock state changes from locked to unlocked, and a time stamp two value when the vehicle lock state changes from unlocked to locked, then communicate, at the time stamp one value, with the central database to store the time stamp one value.
Skertic teaches, in at least Fig(s). 7 & ¶¶13, 39-40, 51-53 & 65that is was old and well known at the time of filing in the art of vehicle control systems, to store a time stamp one value when the vehicle lock state changes from locked to unlocked, and a time stamp two value when the vehicle lock state changes from unlocked to locked, then communicate, at the time stamp one value, with the central database to store the time stamp one value (Skertic, in at least Abstract, Fig(s). 7 & ¶¶13, 39-40, 51-53 & 65, teaches a vehicle security and monitoring control (VSMCM) controller to lock/unlock doors, and/or enable/ disable vehicle operation of the control module within the vehicle, wherein a base station communicates with the VSMCM controllers to record events and vehicle information taken by the controllers, wherein databases holding information about vehicles parked on the dealership lot, to analyze trends based upon events/activities reported by the VSMCM controllers. Skertic further teaches upon initial startup of the process (82), the system is initialized (84) from the database and the communications protocol is auto detected (86), the state of the system is then set to Monitor (88) and the event is transmitted back to the base station (16) where the event is time stamped with the time (90) from the clock in the Personal Computer (PC) (30) and recorded/logged, wherein when the base station (16) receives an event message (914), the message is record/logged in the event log (916)).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Jefferies in view of Skertic with a reasonable expectation of success, as both inventions are directed to the same field of endeavor – vehicle access control systems and the combination would guarantee the vehicle security and prevent theft or misuse of the vehicles (see at least Skertic’s ¶¶9-10).
As per claim 2, Jefferies as modified by Skertic teaches the system of claim 1, accordingly, the rejection of claim 1 above is incorporated. Jefferies further discloses wherein the dongle device communicates with an on-board diagnostics port of the first vehicle (Jefferies, in at least Fig. 8 [reproduced above for convenience] and ¶¶255-256, discloses dongles, mailed to participants, who self-installed them by connecting the dongle to the vehicular on-board diagnostic port).
As per claim 3, Jefferies as modified by Skertic teaches the system of claim 1, accordingly, the rejection of claim 1 above is incorporated. Jefferies further discloses wherein the dongle device is permanently coded to the vehicle VIN (Jefferies, in at least Fig(s). 13A-B & 24E and ¶¶177-188, discloses the IVA queries the vehicle ECU over the CAN bus in order to obtain the Vehicle Identification Number (VIN), wherein the VIN is stored in memory and used in order to determine the vehicle's identity, which then allows the appropriate codes to be determined depending on how the codes are stored. Jefferies further discloses the VIN is instead sent via the wireless network connection to the remote computing system, wherein the remote computing system may then determine the correct codes to use by decoding the VIN to lookup in a database the correct command codes and/or executable instructions to transmit back to the IVA over the wireless network/Internet, wherein the codes, e.g., command codes or executable instructions, is received by the IVA and stored in an appropriate table for lookup, access, and use to enable car commands such as unlocking the doors, etc. Jefferies also discloses the external hub connected to the vehicle’s OBD2 diagnostic port performs the same query for the VIN over the CAN bus, wherein once the VIN is obtained, the VIN then is stored in memory and/or compared to existing VINs in memory).
As per claim 4, Jefferies as modified by Skertic teaches the system of claim 1, accordingly, the rejection of claim 1 above is incorporated. Jefferies further discloses wherein the set of terms and conditions comprise a designated geographical area outside of which the app cannot change the vehicle locked state from locked to unlocked (Jefferies, in at least Fig(s). 6A-B and ¶¶6-26, 78, 97, 167, 176 & 219, discloses In-Vehicle Applications (IVA) 204, configured to be run on the infotainment unit of the vehicle access and management system, collects trip logs, which include start/end locations, date/time, miles driven, duration of trip, max speed, average speed, max acceleration, fuel level, etc., as well as whether extreme acceleration or braking occurred, whether the engine was ever turned on without proper access (unauthorized user), the maximum speed, and whether the vehicle has left a certain geographical area. Jefferies further discloses vehicle settings associated with data collected during the operation of the vehicle, wherein data is kept on the miles driven, the dates and times of vehicle operation, the total drive time, the start/end locations for trips and path taken, any rapid and extreme acceleration/cornering/braking, and air bag deployment. Jefferies also discloses the remote server 1602 generates an access code to be sent to the mobile application for storage, along with all relevant reservation data, i.e., length of reservation, dates, times, destination, starting places, prices for all services, services included, etc., wherein the access code is then used to access the car in a variety of ways, e.g., the access code itself is transmitted from the remote servers 1602 to the vehicle. Then, if the access code is presented by the mobile device 206 to the IVA 1604/external hub, e.g. for example, using RFID/NFC with RFID Reader 302 [implies designated geographical area outside of which the app cannot change the vehicle locked state, i.e., RFID range], and it corresponds to the access code on the IVA 1602 or external hub, commands will be sent to unlock all the doors and enable the starter. An example of the access code presented by the mobile device 206 corresponding to the code on the IVA 1602 or external hub includes the access codes matching, wherein the temporary access code is instead sent from the mobile device 206 to the remote servers 1602. If the access code corresponds to the access code that the remote servers 1602 have associated with an active reservation, the remote servers 1602 will send a command to the vehicle to unlock the doors for the customer and enable the starter).
As per claim 5, Jefferies as modified by Skertic teaches the system of claim 1, accordingly, the rejection of claim 1 above is incorporated. Jefferies further discloses wherein the user, by way of the user device, communicates at least part of the vehicle VIN to the dongle device to enable the dongle device to change the vehicle lock state from locked to unlocked (Jefferies, in at least Fig(s). 13A-B & 24E and ¶¶177-188, discloses the In-Vehicle Applications (IVA) queries the vehicle ECU over the CAN bus in order to obtain the Vehicle Identification Number (VIN), wherein the VIN is stored in memory and used in order to determine the vehicle's identity, which then allows the appropriate codes to be determined depending on how the codes are stored. Jefferies further discloses the VIN is instead sent via the wireless network connection to the remote computing system, wherein the remote computing system then determines the correct codes to use by decoding the VIN to lookup in a database the correct command codes and/or executable instructions to transmit back to the IVA over the wireless network/Internet, wherein the codes are received by the IVA and stored in an appropriate table for lookup, access, and use to enable car commands such as unlocking the doors, etc. Jefferies also discloses the external hub connected to the OBD2 Port performs the same query for the VIN over the CAN bus, wherein once the VIN is obtained, the VIN then is stored in memory and/or compared to existing VIN s in memory).
As per claim 6, Jefferies as modified by Skertic teaches the system of claim 1, accordingly, the rejection of claim 1 above is incorporated. Jefferies further discloses wherein the vehicle controller is one of: an on-board diagnostics controller, a telematic control unit, an electronic control unit, an electronic control module, and an engine control module (Jefferies, in at least Fig(s). 9, 13A-B & 24E and ¶¶65-67 177-188, discloses electronic control unit(s)(ECU(s)), which is/are embedded systems that control one or more of the electrical systems or subsystems of the vehicle, wherein the In-Vehicle Applications (IVA) queries the vehicle ECU over the CAN bus in order to obtain the Vehicle Identification Number (VIN), and the external hub connected to the OBD2 Port performs the same query for the VIN over the CAN bus, then once the VIN is obtained, the VIN is stored in memory and/or compared to existing VIN s in memory).
As per claim 7, Jefferies as modified by Skertic teaches the system of claim 1, accordingly, the rejection of claim 1 above is incorporated. Jefferies further discloses wherein:
the set of vehicle states further comprises at least one of vehicle fuel level and vehicle engine status; and
the central database records the set of vehicle states when the dongle device is
communicating with the vehicle controller (Jefferies, in at least Fig(s). 6A-B and ¶¶6-26, 78, 97, 167, 176 & 219, discloses the backend includes remote servers, cloud-based servers, and mobile applications running on mobile devices, which is wirelessly connected to the vehicle to allow for monitoring and configuring the vehicle, the provision of connected-vehicle services, and the remote issuing of commands to the various systems of the vehicle. Jefferies further discloses a method of collecting and storing customer specific vehicle usage data (e.g., fuel level, start/end odometer reading, total miles, hours in use, max/average speed, idle time, start/stop dates and time, carbon foot print, driver rating, etc. Jefferies also discloses In-Vehicle Applications (IVA) 204, configured to be run on the infotainment unit of the vehicle access and management system, collects trip logs, which include start/end locations, date/time, miles driven, duration of trip, max speed, average speed, max acceleration, fuel level, etc., as well as whether extreme acceleration or braking occurred, whether the engine was ever turned on without proper access (unauthorized user), the maximum speed, and whether the vehicle has left a certain geographical area. Jefferies furthermore discloses vehicle settings associated with data collected during the operation of the vehicle, wherein data is kept on the miles driven, the dates and times of vehicle operation, the total drive time, the start/end locations for trips and path taken, any rapid and extreme acceleration/cornering/braking, and air bag deployment. Jefferies also discloses the remote server 1602 generates an access code to be sent to the mobile application for storage, along with all relevant reservation data, i.e., length of reservation, dates, times, destination, starting places, prices for all services, services included, etc., wherein the access code is then used to access the car in a variety of ways, e.g., the access code itself is transmitted from the remote servers 1602 to the vehicle. Then, if the access code is presented by the mobile device 206 to the IVA 1604/external hub, e.g. for example, using RFID/NFC with RFID Reader 302, and it corresponds to the access code on the IVA 1602 or external hub, commands will be sent to unlock all the doors and enable the starter. An example of the access code presented by the mobile device 206 corresponding to the code on the IVA 1602 or external hub includes the access codes matching, wherein the temporary access code is instead sent from the mobile device 206 to the remote servers 1602. If the access code corresponds to the access code that the remote servers 1602 have associated with an active reservation, the remote servers 1602 will send a command to the vehicle to unlock the doors for the customer and enable the starter).
As per claims 17-22, the claims are directed towards methods that recite similar limitations performed by the systems of claims 1-7. The cited portions of Jefferies & Skertic used in the rejections of claims 1-7 disclose the same steps to perform the methods of claims 17-22. Therefore, claims 17-22 are rejected under the same rationales used in the rejections of claims 1-7 as outlined above.
As per claims 23-27, the claims are directed towards dongle devices that recite similar limitations performed by the systems of claims 1-7. The cited portions of Jefferies & Skertic used in the rejections of claims 1-7 disclose the same elements and/or limitations of the devices of claims 23-27. Therefore, claims 23-27 are rejected under the same rationales used in the rejections of claims 1-7 as outlined above.
As per claim 28, Jefferies as modified by Skertic teaches the dongle device of claim 23, accordingly, the rejection of claim 23 above is incorporated. Jefferies further discloses wherein:
the set of terms and conditions further comprises a selectable threshold distance between the vehicle and the user device; and
if the selectable threshold distance is exceeded, the vehicle locked state remains locked or changes to locked (Jefferies, in at least ¶¶17, 72, 77, 84, 91, 100, 138, 216-220, 228-229 & 308, discloses other kind of wireless transmission technology may be used, such as for example, RFID (radio-frequency identification) and NFC (near field communication), which are methods of querying information from, and communicating with a radio identification device within a set proximity, wherein to enable customers to bypass the reservation desk and pickup/drop off reserved and non-reserved RCS vehicles using a Quick Response (QR)/Bar code, or Radio Frequency Identification (RFID)/Near Field Communication (NFC)/Bluetooth enabled mobile phone coupled with a mobile app [implies selectable threshold distance, i.e., selected communication technology range, wherein RFID has a wide range, from short for passive tags to long 100+ meters for active tags, NFC has a very short range up to 4 cm, and standard Bluetooth is medium range up to 10 meters]. Jefferies’s infotainment units may utilize Bluetooth technology and/or smartphones to provide a user control, wherein the in-vehicle infotainment unit is configured to access various wireless data connections or communications networks, such as cellular, Bluetooth, GPS, RFID, wi-fi and so forth, wherein wireless technologies that may be used by vehicles and their infotainment units includes cellular Wi-Fi, Bluetooth, ZigBee, Lora, and so forth. Jefferies further discloses the Infotainment Unit 202 connects to Mobile Device 206 using a wireless data connection such as Bluetooth, RFID, Infrared, Wi-fi, or any other NFC technology. Jefferies also discloses a rental-carshare in-vehicle application (RCSIVA) can greatly reduce the costs and resources needed to implement and maintain carsharing and connected car functionality by offering an improvement over current hardware and software implementations, wherein if the vehicle does not have one or all of the required components needed for connected car services, an external hub can be added to provide the required long and short range wireless connectivity and GPS. Jefferies further discloses the external hub or IVA 1604 may be paired to an RFID reader 302 that can detect a mobile device, such as Mobile Device 206. The RFID reader 302 may be able to read RFID/NFC/Bluetooth or other wireless signals. This allows Mobile Device 206 to be easily identified when in close-enough proximity, wherein a mobile application that can control the car's functionality after authentication and authorization of the user (such as through a login, where the user is authorized to control the car (e.g. they rented the car), or if the car can tell that the user is in close proximity, e.g. through a QR/Bar code scan, RFID communication, NFC, or ad hoc wireless networking).
As per claim 29, Jefferies as modified by Skertic teaches the dongle device of claim 23, accordingly, the rejection of claim 23 above is incorporated. Jefferies further discloses wherein:
the set of terms and conditions further comprises a set of vehicle types; and
if the vehicle is not one of the set of vehicle types, the vehicle locked state remains locked or changes to locked (Jefferies, in at least ¶¶10, 62, 82, 175 & 178, discloses being universal in nature and designed to auto-configure or be quickly configured to a specific type of vehicle, wherein the system is used with various years, makes, and models of vehicles, wherein this universality also allows for reduction in installation time and increased reliability. Jefferies further discloses the vehicle access and management systems described is utilized with any kind of communication system present in any type of vehicle, and are not restricted to communication systems associated with the CAN protocol, wherein the IVA or the external hub is configured with sets of executable instructions or command codes to use with many different types of vehicles).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. See attached & previously mailed PTO-892 forms.
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 extension fee 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 Tarek Elarabi whose telephone number is (313)446-4911. The examiner can normally be reached on Monday thru Thursday; 6:00 AM - 4: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, Peter Nolan can be reached on (571)270-7016. The fax phone number for the organization where this application or proceeding is assigned is (571)273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair.
Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or (571)272-1000.
/Tarek Elarabi/Primary Examiner, Art Unit 3661