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
This Office Action is in response to the Request for Continued Examination filed on 3/24/2026. Claims 1 - 20 are amended. Claims 1-20 are presently pending and examined.
Prosecution History
Applicant originally filed Claims 1-20.
Applicant filed RCE and amended Claims 1 – 20. Claims 1-20 are pending and presented for examination.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/11/2026 has been entered.
Response to Arguments
Prior Art Rejection
Applicant’s amendments and accompanying arguments, see remarks, filed 3/24/2026, with respect to the rejection(s) of claim(s) 1-20 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Venkata Naga Siva Vikas Vemuri et. al. US20220386094 (“Vemuri”) and NPL “Service requirements for enhanced V2X scenarios (3GPP TS 22.186 version 16.2.0 Release 16) ETSI TS 122 186 V16.2.0 (2020-11) (“3GPP Standard”).
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.
The factual inquiries 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 nonobviousness.
Claim(s) 1-5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Venkata Naga Siva Vikas Vemuri et. al. 20220386094 (“Vemuri”) in view of William David Duncan et. al. US20180308363A1 (“Duncan”) and further in view of Shingo Sugimoto et. al. US 20220322200 (“Sugimoto”) and NPL “Service requirements for enhanced V2X scenarios (3GPP TS 22.186 version 16.2.0 Release 16) ETSI TS 122 186 V16.2.0 (2020-11)” (“3GPP Standard”).
As per Claims 1, 9 and 17
Vemuri discloses,
receive a request from a software application installed on the vehicle to perform an identification of vehicle connectivity (IVC) check, (see at least [0008] the request message includes a list of software applications, [0070] The requesting vehicle broadcasts its intention to create a platoon and to run a host of predetermined Game APPS, and [0068] FIG. 7 shows a block flow diagram of an exemplary method 700 for facilitating on-demand wireless connectivity and data pooling by forming a platoon of vehicles to meet the required operating parameters for online gaming. The method starts in block 702.)
receive a message from another vehicle in proximity to the vehicle, (see at least [0008] the reply message includes confirmation that at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications, and [0052] the lead vehicle 108 of the platoon 100 verifies the platoon's wireless quality-of-service (QoS) and quality-of-experience (QoE) capabilities and availability of APPS desired by the requesting vehicle)
wherein the message comprises information about the other vehicle (see at least [0055] The request message includes mandatory platooning parameters and application wireless radio/data needs)
and is received within a predefined search area that is an area within which the vehicle searches for messages from surrounding vehicles, (see at least [0066] Moving to block 622, the potential host vehicle's wireless QoS/QoE metrics is received by the requesting vehicle. Moving to block 624, the requesting vehicle determines if the potential host vehicle's wireless QoS/QoE metrics meets a predetermined minimal requirements for operating ADAS and smart vehicle APPS, [0071] Moving to block 706, if no potential host vehicle is available, the method 700 proceeds to block 708 where the requesting vehicle continues searching for potential host vehicles within the predetermined radius and time interval. Referring back to block 706, if a potential host vehicle having gaming capabilities is available, the method 700 moves to block 710 where the requesting vehicle sends a request to the potential host vehicle to form a platoon, and [0073] the potential host vehicle sends the potential vehicle's platooning capabilities. Moving to block 718 the requesting vehicle determines whether the potential host vehicle's platooning capabilities meets a predetermined minimal standard)
detect a connected vehicle within the new search area from among the surrounding vehicles via a message from the connected vehicle (see at least [0053] if the platoon is capable of meeting the on-demand QoS and QoE needs of the requesting vehicle, then the method 300 moves to block 316 where the lead vehicle sends a “join accepted” with platooning parameters and a join slot number to the requesting vehicle. The method then moves to block 318, where the requesting vehicle joins the platoon and the requesting vehicle's APP usage may be offloaded from the cellular network to the data-pipe 111 of the platoon using V2V or D2D communications for mobile edge computing, and [0067] If the minimal requirement is satisfied, then the method moves to block 628 where the requesting vehicle joins the platoon. The method ends in block 630).
Vemuri further discloses,
identify a parameter for the IVC check corresponding to the software application from a lookup table containing a list of parameters corresponding to different software applications (see at least [0066] In block 620, the requesting vehicle request the potential host vehicle's wireless QoS/QoE metrics for ADAS APPS and smart vehicle APPS. Moving to block 622, the potential host vehicle's wireless QoS/QoE metrics is received by the requesting vehicle, [0066] For example, the minimal requirements may be 5G QoS for assisted vehicle video buffering, a guaranteed bit rate (BR) with packet budget rate of 75 ms. and packet error rate (PER) of 10-2. In case of V2X messages for platooning the PER is 10-2 and BR is 50 ms., [0069] the requesting vehicle searches within a 3 mile parameter and in 3 minute intervals for a potential host vehicle equipped with ADAS, wireless communications, and gaming capabilities, and [0051] The requesting vehicle also transmit a list of desired applications (APPS) to be utilized by the requesting vehicle).
modify the predefined search area based on the parameter and information about the other vehicle to create a new search area (see at least [0049] the requesting vehicle may utilize one or more of V2V communications, D2D communications, and C-V2X to search for a platoon of vehicles within a predetermined radius from the requesting vehicle. The predetermined radius may be expanded out to a few miles such as a 3 mile radius, and [0052] if the platoon does not meet a predetermined on-demand QoS and QoE needs of the requesting vehicle, then the method 300 moves to block 308, where the requesting vehicle continues searching within the predetermined radius and at the predetermined time intervals until another platoon of vehicles is found or the operator ends the method at block 320).
Vemuri fails to explicitly disclose,
“from a lookup table containing a list of parameters” and “modify the predefined search area based on the parameter”
However, 3GPP Standard teaches,
from a lookup table containing a list of parameters (see at least [Page 9] Table 5.2-1 Performance requirements for Vehicles Platooning, [Page 10] Table 5.3-1 Performance requirements for advanced driving, [Page 11] Table 5.4-1 Performance requirements for extended sensors, and [Page 11] Table 5.5-1 Performance requirements for remote driving), and
modify the predefined search area based on the parameter (see at least [Page 7., Section 5.1] [R.5.1-001] The 3GPP system shall be able to control the communication range for a message based on the characteristic of the messages transmitted by a UE supporting V2X application)
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications and 3GPP Standard teaches service requirements to enhance 3GPP support for V2X scenarios in the 3GPP systems for safety and non-safety V2X scenarios.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with providing quality of service information to the V2X application in a resource efficient way as taught by 3GPP Standard, with a reasonable expectation of success, to enable a V2X application to be timely notified of expected or estimated change of quality of service before actual change occurs and to enable the 3GPP System to modify the quality of service in line with V2X application’s quality of service needs (Page 7, Section 4.1).Vemuri does not disclose,
detect an identifier of the software application from information included in the request,
Duncan teaches,
detect an identifier of the software application from information included in the request (see at least [0007] The characteristic of the automatic-driving software program may include an identification of the automatic-driving software program)
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) and Duncan teaches dynamically determining a parameter to identify connected vehicles based on the identifier.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the method of determining characteristics including identification of an autonomous driving software program as taught by Duncan, with a reasonable expectation of success, to make driving and/or collision avoidance decisions (0024).
Vemuri does not disclose,
wherein the message comprises information about the other vehicle,
Sugimoto teaches,
wherein the message comprises information about the other vehicle (see at least [0019] The first vehicle 102, the second vehicle 104, and the third vehicle 106 may be communicatively linked to form the mesh network system 100. The mesh network system 100 may include a routing table that includes a vehicle identification (e.g., communications unit identification numbers, IP address, or other information related to the first vehicle 102, the second vehicle 104, and the third vehicle 106), [0036] if vehicle 430 requests data or a service from vehicle 410, the routing table may identify a path for vehicle 430 to communicate through the neighboring vehicles, such as vehicle 420 and 440. The vehicle 430 may be the source or requesting vehicle in this example, where the vehicle 430 communicates through the established route of nodes based on the routing table, and [0056] each of the vehicles, for example, the first vehicle 102, the second vehicle 104, and the third vehicle 106, when in range of each other, may share their speed, heading, position, destination information or the like with each other or the computing device 192).
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications and Sugimoto teaches a dynamic network routing protocol for communication between vehicular nodes of a mesh network.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the use of time out parameter as taught by Sugimoto, with a reasonable expectation of success, to identify vehicles to be included in the mesh network based on vehicle travel characteristics ([0062]).
As per Claims 2, 10 and 18
Vemuri does not disclose,
when the processor detects the identifier, the processor is configured to:read the identifier from the request.
Duncan teaches,
when the processor detects the identifier, the processor is configured to:read the identifier from the request (see at least [0067] software programs (e.g., software programs configured to operate on a processor 130) that it uses to determine the time-varying handling characteristic, and [0087] The record may include an indication of the characteristic of performance (e.g., an identifier for the characteristic) and/or the value of the characteristic of performance).
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) and Duncan teaches dynamically determining a parameter to identify connected vehicles based on the identifier.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the method of determining characteristics including identification of an autonomous driving software program as taught by Duncan, with a reasonable expectation of success, to make driving and/or collision avoidance decisions (0024).
As per Claims 3, 11 and 19
Vemuri discloses,
wherein the parameter is an error margin parameter to identify connected vehicles (see at least [0066] the requesting vehicle determines if the potential host vehicle's wireless QoS/QoE metrics meets a predetermined minimal requirements for operating ADAS and smart vehicle APPS. For example, the minimal requirements may be 5G QoS for assisted vehicle video buffering, a guaranteed bit rate (BR) with packet budget rate of 75 ms. and packet error rate (PER) of 10-2. In case of V2X messages for platooning the PER is 10-2 and BR is 50 ms.)
wherein the processor is configured to: check connectivity of the vehicle based on the error margin parameter (see at least [0052] the lead vehicle 108 of the platoon 100 verifies the platoon's wireless quality-of-service (QoS) and quality-of-experience (QoE) capabilities and availability of APPS desired by the requesting vehicle).
As per Claims 4, 12 and 20
Vemuri discloses,
wherein the parameter is time allowed parameter that defines a maximum time within which to identify the connected vehicle ([0052] where the requesting vehicle continues searching within the predetermined radius and at the predetermined time intervals until another platoon of vehicles is found or the operator ends the method at block 320).
wherein the processor is configured to: check connectivity of the vehicle based on the time allowed parameter (see at least [0050] Moving to block 306, if a platoon of vehicles is not detected within the predetermined radius, then the method 300 moves to block 308 where the requesting vehicle continues searching within the predetermined radius and at a predetermined time interval, for example every 3 minutes).
As per Claims 5 and 11
Vemuri does not disclose,
wherein the processor is configured to: detect a current speed of the vehicle
wherein, when the processor identifies the parameter, the processor is configured to: identify the parameter based on the current speed of the vehicle.
Sugimoto teaches,
wherein the processor is configured to: detect a current speed of the vehicle (see at least Fig. 6, [0058] The process of the flowchart 600 in FIG. 6 may be executed at various times and intermittently repeated (e.g., every minute, five minutes, etc.) to confirm membership of vehicles to a mesh network, and [0059] At block 602, a mesh network system (e.g., via a computing device 192 and/or an electronic control unit 130), may receive a vehicle status, such as a motion state (e.g., stationary, non-stationary, movement pattern, proximity state, etc.).
wherein, when the processor identifies the parameter, the processor is configured to: identify the parameter based on the current speed of the vehicle (see at least [0060] At block 604, the mesh network system may determine a mesh networking routing mode based on the vehicle status. For instance, if the motion state indicates that the vehicle ignition is on, a speed is above a threshold speed (e.g., non-stationary, above 10 miles per hour, etc.), and not tracking other vehicles (e.g., does not include a common motion state), then the mesh network system may determine to select the dynamic routing protocol at block 608. Otherwise, if the motion state indicates that the vehicle is in a stationary motion state (e.g., such as with an ignition off, a speed at zero, etc.), a motion state indicative of slow movement (e.g., below a threshold speed), and/or the vehicle has a common motion state with other vehicles (e.g., position of moving vehicles is not changing), then the mesh network system may determine to select the static routing protocol at block 606.)
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications and Sugimoto teaches a dynamic network routing protocol for communication between vehicular nodes of a mesh network.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the use of time out parameter as taught by Sugimoto, with a reasonable expectation of success, to identify vehicles to be included in the mesh network based on vehicle travel characteristics ([0062]).
As per Claims 7 and 15,
Vemuri does not disclose,
wherein the information comprises one or more of a position, a speed, or a size of the other vehicle,
wherein, when the processor identifies the parameter, the processor is configured to: identify the parameter based on the one or more of the position, the speed, or the size.
Sugimoto teaches,
wherein the information comprises one or more of a position, a speed, or a size of the other vehicle, (see at least [0059] At block 602, a mesh network system (e.g., via a computing device 192 and/or an electronic control unit 130), may receive a vehicle status, such as a motion state (e.g., stationary, non-stationary, movement pattern, proximity state, etc.).
wherein, when the processor identifies the parameter, the processor is configured to: identify the parameter based on the one or more of the position, the speed, or the size (Fig. 6, Fig. 7, [0019] the computing device may further determine member vehicles to be included in a mesh network system 100 based on their distance from each other, destination, speed, traveling path, or the like. These parameters may be dependent on speed and heading information or independent therefrom).
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications and Sugimoto teaches a dynamic network routing protocol for communication between vehicular nodes of a mesh network.
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the use of time out parameter as taught by Sugimoto, with a reasonable expectation of success, to identify vehicles to be included in the mesh network based on vehicle travel characteristics ([0062]).
Claim(s) 6, 8, 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Vemuri, Duncan, Sugimoto and 3GPP Standard as applied to Claim 1, and further in view of John Anthony Dougherty et. al. US20200207360 (“Dougherty”).
As per Claims 6 and 14,
Vemuri discloses,
Wherein, wherein messages are periodically exchanged between the vehicle and the connected vehicle (see at least [0002] Advance Driver Assisted Systems (ADAS) can be enabled to wirelessly connect and exchange information with other ADAS equipped vehicles to allow for the coordinated movements between such vehicles, [0021] the method further includes using, by the requesting vehicle, the cellular-to-vehicle (C-V2X) communication to exchange information with the vehicle platoon for executing the at least one APP before joining the vehicle platoon)
Vemuri fails to explicitly disclose, that the messages are periodically exchanged.
However, Dougherty teaches,
messages are periodically exchanged (see at least [0183] the method 1500 may be performed for each identified nearby vehicle, and may be performed continuously or periodically to update ACM values, such as based on observations of driving behaviors).
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications and Dougherty teaches detecting a connected vehicle and using the parameters to exchange messages with surrounding vehicle(s).
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the use of time out parameter as taught by Dougherty, with a reasonable expectation of success, to adjusting a driving parameter of the autonomous vehicle based on the determined autonomous capability metric of each of the identified vehicles ([0004]).
As per Claims 8 and 16,
Vemuri does not disclose,
wherein the processor is further configured to generate and send a routing instruction to a user interface of the vehicle based on the connected vehicle
Dougherty teaches,
wherein the processor is further configured to generate and send a routing instruction to a user interface of the vehicle based on the connected vehicle (see at least Fig. 2, [0037] determine whether there would be significant benefits entering into a cooperative driving engagement with those vehicles, determine whether the added benefits outweigh the cost or added time of taking an alternative route. The host vehicle could alter its planned route to follow an alternative route and initiate/engage in a cooperative driving engagement in response to determining that added benefits outweigh the cost or added time, [0075] The vehicle management system stack 200 may output vehicle control commands or signals to the drive by wire (DBW) system/control unit 220, and [0080] The route planning layer 210 may utilize the HD map, as well as inputs from an operator or dispatcher to plan a route to be followed by the host vehicle 100 to a particular destination.
Thus, Vemuri discloses a method of facilitating on-demand wireless connectivity and data pooling with a vehicle platoon where at least one of the participating vehicles is configured to execute at least one software application (APP) on the list of software applications and Dougherty teaches detecting a connected vehicle and using the parameters to exchange messages with surrounding vehicle(s).
As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide the inventions as disclosed by Vemuri with the use of time out parameter as taught by Dougherty, with a reasonable expectation of success, to adjusting a driving parameter of the autonomous vehicle based on the determined autonomous capability metric of each of the identified vehicles ([0004]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Applicants should take note of the prior art in the PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHUTOSH PANDE whose telephone number is (571)272-6269. The examiner can normally be reached Monday -Friday 9:00am -5: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, Fadey Jabr can be reached at 5712721516. 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.
/A.P./Examiner, Art Unit 3668 Supervisory Patent Examiner, Art Unit 3668/Fadey S. Jabr/
Prosecution Insights