A published patent application is not a product; it is a roughly eighteen-month-delayed look at where a company was putting its engineering effort when it filed. Follow that and you see where the money went before it reaches a showroom. For Volvo Car Corporation, eleven applications published on April 2, 2026 — an unusually concentrated single-day batch — and they do not describe a new vehicle. They describe software: two clusters of it, around coordinating cars into groups and around orchestrating how electric cars charge.

The fleet-coordination cluster is the more autonomy-adjacent of the two. US20260094522A1 covers forming a vehicle fleet: receiving join requests from multiple vehicles, categorizing them, determining a lead vehicle and follower vehicles, assigning an order based on real-time travel-path information, and establishing a "daisy chain connection" within the fleet. Its companion, US20260094523A1, covers maintaining that chain: detecting a lost vehicle, identifying its preceding and succeeding vehicles by order, and routing around the gap to keep the group connected. The classifications (G08G 1/22 cooperative-driving, G05D 1/246 and G05D 1/6985 autonomous-control) place this in the platooning-and-coordination corner. Filing on both the formation and the failure-recovery of a managed vehicle group is the kind of work a company does when it expects cars to operate as coordinated fleets, not just as individuals.

Assign an order to each vehicle based on real-time travel path information and the categorization of the plurality of vehicles; communicate a command to the lead vehicle and the one or more follower vehicles to create the vehicle fleet based on the order.— Method of forming a daisy chain connection, US20260094522A1

The charging-and-energy cluster

The larger group of filings is about electrons, not coordination, and it reads as a build-out of charging intelligence. US20260091703A1 covers location-based energy management: detecting via GPS that a vehicle moved from one geographic range to another, connecting to a second grid in the new range, and commanding the battery-management system to charge or discharge using an AI engine trained on charging and discharging data across grids over time. US20260091702A1 covers adaptive charging scheduling: predicting whether a vehicle will reach a charging location near the reserved session start with a target state-of-charge, calculating an "urgency score" for delays, and modifying the reservation plan accordingly. US20260091699A1 covers multi-contact charging and discharging, letting the system charge or discharge individual portions of a battery pack against a user preference and monitor each portion's parameters in real time.

Together those three point to grid-aware, reservation-aware, pack-level charging control — the software that decides not just whether to charge but where, when, and which part of the battery, with vehicle-to-grid discharge in the mix. The common thread is that all three treat charging as an optimization problem rather than a switch: the location filing trains an AI engine on cross-grid charging history, the scheduling filing scores delays and rewrites reservations, and the multi-contact filing controls portions of the pack independently against a stated user preference. Filing across all three at once — the where, the when, and the how-granular — is the pattern of a company building an energy-management layer rather than a single charging feature. US20260091688A1 sits at the hardware edge of the same electrification theme, covering a double-fed induction machine paired with a second electric machine across two axle drives for all-wheel drive.

The connected-vehicle plumbing underneath

A third, smaller set of filings fills in the connectivity and accessory layer the other two clusters rely on. Three applications — US20260094478A1, US20260091673A1, and US20260092970A1 — all cover a vehicle establishing a connection with an attached item (a trailer or accessory) and then testing, assisting, or actuating that item's devices, including via a generated test pattern. US20260093796A1 covers a vehicle selecting, via a machine-learning model, which segment of its status information to release to a responder device based on the responder's role and authorization level — access-control software for vehicle data. That last filing is worth pausing on, because it shows the same machine-learning emphasis that runs through the charging cluster being applied to a different problem: not energy, but who is allowed to see what a connected car knows about itself. A road-side responder, a fleet operator, and a service technician each get a different slice, decided by a model rather than a fixed rule.

One more application rounds out the chassis-and-comfort edge of the batch. US20260091634A1 covers detecting a road deformity such as a speed bump from a distance using vehicle sensors, determining the ground clearance needed to clear it and a comfort level based on the occupant's state, then temporarily adjusting a vehicle parameter to clear it. Classified across suspension control (B60G 17/0165) and the B60W driver-assistance classes (B60W 30/143, B60W 50/14, B60W 2420/403), it is a sensing-to-actuation filing that ties the perception stack to the active chassis — the same sense-then-act pattern the fleet and charging filings apply to coordination and energy.

Read as a body, the eleven applications point in a consistent direction: the filing volume is in software and connectivity around a connected, electrified car — coordinating vehicles into managed groups, orchestrating charging against the grid, and managing the data and accessories that connect to the vehicle. The inference the records support is grounded and narrow: this is investment in the coordination-and-energy software layer, disclosed roughly eighteen months before it would reach customers. What the cluster does not establish is which of these features ships, when, or whether any of it shows up as revenue — a published application is R&D made visible, not a product on sale.