Investigation
Bend Privacy Alliance / Axon patents series, Part 5 of 11 · September 2026
What Bend bought, what Fusus built, and what its patents say surveillance can become
In March 2023, Bend City Council approved a three-year agreement with a company called Fusus. The City described the purchase as software and hardware that would allow police to view public and community video sources for “incident situational awareness and investigations.” Council authorized up to $230,000 on the consent agenda. Bend City Council agenda, March 15, 2023
That description was accurate, but the underlying agreement described something considerably more capable.
Bend contracted for an environment that could bring together public and private video feeds, dispatch information, drones, body cameras, license-plate readers and other sources. The package included FususCORE gateway devices, an Elite AI appliance, panic-alert functions, a community camera registry and a product called fūsusOVERWATCH.
Its purpose was unusually easy to understand: allowing users to track vehicles and people from one camera to another.
That is a useful starting point for understanding Fusus, because it is easy to mistake the system for a better way of displaying cameras. Its more consequential function begins after the cameras and data sources are connected.
A single camera observes a place. A connected network can help observe movement between places, while software can make it easier to decide which part of that network an operator should look at next.
Fusus arrived after the sensors did
Bend’s procurement history makes that architecture easier to see.
The City’s Axon relationship did not begin with Fusus. Bend approved body-worn cameras and digital-evidence services in 2021. Fleet 3 in-car cameras followed in 2022, with the underlying procurement including mobile automated license-plate-reader capability. That same year Bend added Axon Air drone services, including advanced-streaming and API-integration capabilities.
Then, in March 2023, Bend bought Fusus.
The order is important because Fusus did not arrive as a new collection device looking for something to collect. It arrived after Bend already had body cameras, vehicle cameras with mobile ALPR and drone technology capable of transmitting video.
Fusus supplied an interoperability layer capable of bringing categories of those systems together.
The original Fusus agreement contemplated CAD integration, public and private cameras, body cameras, drones, automatic vehicle location, covert video, license-plate readers and future video feeds. Its initial equipment included FususCORE devices that could connect existing camera systems to the platform, along with a CORE Elite AI appliance.
This is what makes an interoperability platform different from an ordinary camera purchase: its capability can expand when something else is added around it.
A new compatible camera can become another potential viewpoint. A drone can become another live video source. A connected patrol vehicle can contribute location or video. A plate reader can produce another stream of vehicle-location events. A privately owned camera can become another node in the network.
The integration platform does not necessarily have to be repurchased each time one of those underlying systems changes. That makes the cumulative architecture difficult to see if each procurement is evaluated on its own.
A camera sees a place. A network can follow movement.
A conventional surveillance camera has a straightforward limitation: once a person or vehicle leaves its field of view, an operator has to determine where the subject might appear next, find another camera and switch feeds.
Fusus was designed to reduce that friction.
Commercial descriptions of Overwatch describe locating people and vehicles from one camera to another by identifying cameras near the current view and updating the surrounding camera choices as operators select new views. The patent research found Overwatch to be the strongest commercial match to Fusus’ object-tracking patent family.
The patent family itself has an unusually descriptive title: “Crime center system providing video-based object tracking using an active camera and a 360-degree next-up camera set.”
Its architecture models where cameras are physically located and can incorporate information about the direction they face. A person or vehicle appears in the active camera. The software identifies other cameras that may be useful, presents them to the operator, and recalculates the surrounding choices when another camera becomes active.
In simple terms:
Camera A → potentially useful nearby cameras → Camera B → new set of nearby cameras → Camera C.
The later continuation goes further. It expressly discusses determining the tracked object’s direction of travel and future route, while narrower claims and the specification describe predicting when other cameras are expected to capture the object. US20250225666A1
This is where the evidence needs to remain separated. There is strong commercial evidence that Overwatch supports camera-to-camera following of people and vehicles. The patents describe additional functions involving movement prediction and other forms of automation, but that does not establish that all of those functions are commercially available or enabled in Bend.
The patent tells us what engineers claimed and described. Product documentation tells us what the company offers. Local configuration records are needed to establish what Bend actually uses.
The patents begin asking where the target will appear next
The later object-tracking continuation changes the operating question.
The basic Overwatch problem is:
Which camera should I look at next?
The patent application develops that into:
Where is this person or vehicle likely to go, and which camera should see it next?
Its claims include determining a future route for a tracked object and presenting that route through an interface; the application also describes camera-specific timers for when the tracked object is predicted to reach another camera, using factors including speed, direction, camera location and field of view. US20250225666A1
The application was filed in March 2025, after Axon’s acquisition of Fusus, and remains pending. Application claims can change before issuance.
Current public Fusus documentation also does not establish that the complete future-route and predicted-arrival architecture described in the patent is a generally deployed product feature.
So the defensible conclusion is narrower but still consequential:
Fusus commercially supports camera-to-camera tracking, while its continuing patent portfolio describes increasingly sophisticated ways to anticipate where a tracked person or vehicle may appear next.
The same idea can work backward
Another Fusus application takes the movement problem in a different direction by using isochrones—geographic boundaries representing places a subject could plausibly reach within a particular time.
Starting with information such as a known location, time, speed and direction, the system can generate a geographic search area and identify cameras within it. Roads, obstacles, terrain and direction can make that predicted region very different from a simple circle.
The particularly significant part is that the time window can extend backward as well as forward.
The system can conceptually ask:
Where might this vehicle be 15 minutes from now?
But it can also ask:
Where could this vehicle have been 15 minutes before it appeared here?
That turns a known observation into the starting point for a retrospective camera search—identifying locations a person or vehicle plausibly passed through and prioritizing cameras in those areas. The published international application is WO2025128824A1, “Methods and systems for video-based object tracking using isochrones.”
Our patent research classifies this as disclosed patent architecture rather than a confirmed current Bend capability. The same is true of automatic reacquisition, future-route prediction and an automatic bridge from ALPR into predictive tracking.
The value of the patent here is not that it proves Bend is using isochrones. It tells us what configuration and product questions are worth asking.
Fusus connects events and data, not just cameras
Thinking about Fusus only as a hardware connector still understates the system.
Some inputs are physical devices: body cameras, Fleet cameras, fixed security cameras, drones and privately owned cameras.
Others are information those devices create: license-plate reads, device locations, vehicle characteristics and alerts.
Still others are operational events: a CAD call, incident location, responder location or panic alert.
The original Fusus patent architecture was built around precisely this kind of heterogeneous environment. It describes public and private cameras, mobile and fixed video, responder locations, dispatch information, multimedia tips, license-plate alerts, gunshot alerts, IoT information and incident evidence as ingredients of a common real-time crime-center environment.
Current Axon documentation makes that concept concrete. Axon says Body 3, Body 4 and Fleet 3 work with Fusus, along with Axon Air drones when integrated. It also states explicitly that what users can see and do depends on an agency’s hardware, licensing and configuration. Axon Fusus FAQ
That qualification leads to a better oversight question: not simply whether Fusus can display a particular kind of information, but whether Bend has enabled the connection and who has permission to use it.
Bend’s sensor inventory shows the collection points that can potentially feed a larger surveillance environment. An inventory alone does not establish which sources are linked or which features are enabled.
Fleet shows why contracts no longer reveal the technical boundaries
Bend’s Fleet 3 system is a particularly useful example.
Fleet arrived before Fusus, and when Bend consolidated most of its Axon agreements in 2024, Fleet was expressly left under its existing contract. The October 2024 Council record says the broader Axon package was intended to consolidate the department’s multiple Axon contracts while the Fleet arrangement remained separate. Bend October 2024 Axon issue summary
Contractually, Fleet remained apart. Current Axon documentation, however, identifies Fleet 3 as a supported source in the Fusus ALPR environment. Fusus administrators can manage plate-read permissions, retention, hotlist settings and map access through Axon Evidence, with those permissions synchronized into Fusus. Axon Fusus ALPR Experience
That gives Bend a real-world example of why procurement silos do not necessarily map to technical silos. A device does not have to appear on the same invoice as Fusus to become useful inside the Fusus environment.
The contract tells us how Bend bought Fleet; configuration records would tell us whether Bend currently sends Fleet ALPR data into Fusus.
Body and Fleet connections are configurable too
Axon’s current configuration guide makes the distinction even clearer.
For supported body cameras, administrators can separately enable location information and livestream access for Fusus. Body 3 and Body 4 location can appear on the Fusus map when the appropriate setting is enabled, while another setting allows authorized users to view audio and video livestreams. Axon Fusus configuration guide
Fleet 3 has parallel settings. One allows vehicle GPS data to appear in Fusus; another enables Fleet 3 livestream access. Axon says these controls are managed in Axon Evidence.
The permissions can also be separated by device category. A role can be allowed to see one kind of device while being denied access to drones or Fleet, and location access can be separated from livestream access. Axon Fusus configuration guide
Current Fusus documentation further says that connected Body, Fleet and Air devices can appear on the map, with livestreams available where the organization has the necessary licensing and permissions. Axon Fusus map documentation
This establishes that the integration is commercially real. It still does not tell us which switches Bend has turned on.
Private cameras can expand the network without the City buying cameras
Fusus also extends beyond government-owned equipment through Bend’s Connect Bend program.
A private camera can be registered, meaning police know that a camera exists at a location and can request footage later. Or a compatible camera system can be integrated, giving it a potentially different relationship to the Fusus environment through FususCORE.
Those arrangements create different capabilities: registration creates a directory of potential evidence sources, while integration creates a potential live node in the network.
The Bend Bulletin reported 618 registered cameras and 174 integrated cameras on March 4, 2026. A Bend Privacy Alliance observation of the Connect Bend site on August 9, 2026 showed 764 registered and 322 integrated cameras. The two figures come from different source types, so the later count should be read as a dated BPA field observation rather than an independently reported number.
An integrated camera has the potential to participate in real-time operations under the rules and permissions governing that connection. And the camera owner is not the only person affected: employees, customers, tenants, delivery drivers, visitors and passersby may be recorded by cameras whose integration decisions they did not make.
The patents anticipated conditional private-camera access
One issued Fusus patent describes a model called Policy Based Sharing in which a private camera can remain unavailable to public safety during ordinary conditions and become accessible when a defined emergency event occurs. Some claimed embodiments contemplate the event being detected automatically rather than requiring a person to press a panic button. US11443613B2
That design can be more protective than continuous government access. But it also means the privacy boundary is partly defined in software. The practical safeguards depend on who defines the trigger, who can change it, how long access remains open, who can view the stream, whether the access is logged, and whether resulting footage can be retained.
Bend’s original Fusus agreement already contemplated panic alerts with location information and nearby-camera docking, so those questions arise from functions within the locally contracted architecture rather than an unrelated hypothetical.
Then Axon bought Fusus
The major institutional shift came in 2024, when Axon acquired Fusus.
Later that year, Bend approved a five-year Axon Officer Safety Plan 10 Premium agreement for up to $2,555,786.51. Bend’s own issue summary says the department was using Axon for body cameras, digital evidence, drone services, professional-review software and real-time information-center software, and that the City wanted to consolidate those previously separate contracts. Bend October 2024 Axon issue summary
The agreement brought the standalone Fusus relationship into that larger Axon environment.
The consolidated procurement included FususONE and continuing FususCORE support, while the broader package encompassed a considerably larger Axon technology ecosystem. The research record shows that the existing standalone Fusus agreement and multiple earlier Axon quotes were superseded effective January 1, 2025.
Before consolidation, Bend’s Axon environment had accumulated body cameras, Evidence, Fleet, ALPR, Axon Air and Fusus through separate purchases and agreements. After consolidation, much of that environment sat within a single Axon contractual relationship.
Fleet remained under its older contract, but Axon now owned the interoperability platform capable of working with Fleet.
Bend’s contract history shows how the City accumulated Axon and Fusus products over time. Contract amounts and product listings do not, by themselves, establish which integrations or features were enabled.
Respond helps explain what changed after the acquisition
The relationship between Axon Respond and Fusus makes the platform convergence especially visible.
Axon’s current documentation says agencies transitioning from Respond keep their existing device status, livestream, alert and location functionality in Fusus. It describes Fusus as adding a redesigned map, multi-camera livestreaming and docking, enhanced alert response and incident tools. Axon Respond-to-Fusus FAQ
Existing Respond roles and permissions also carry into Fusus and continue to be managed through Axon Evidence. Axon Fusus configuration guide
The post-acquisition change is therefore more significant than simply replacing the name of the company supplying Bend’s RTCC software. Fusus has become part of Axon’s own real-time operations layer.
That makes the surrounding Axon ecosystem more relevant to the Fusus conversation, but it still does not mean every Axon product belongs in this article. Records, Standards and other Axon services may be part of the broader platform without being established Fusus surveillance inputs. The safer approach is to identify actual documented connections rather than assume that products integrate merely because Axon sells them.
What Bend bought is still not the same as what Bend uses
At this point, four different kinds of evidence need to stay separate.
A contract can establish that a capability was included. Bend’s 2023 agreement included Overwatch.
A contract can establish that technical prerequisites were present. The same package included FususCORE equipment and a CORE Elite AI appliance.
Vendor documentation can establish that an integration is commercially supported. Axon currently documents Body, Fleet, Air and ALPR functionality within Fusus.
But none of those facts automatically answers the fourth question: Did Bend enable and use that particular capability?
For many of the most consequential integrations, that remains unresolved.
The Fusus patent research reached much the same endpoint. After mapping the patents, commercial product evidence and Bend procurement records separately, the remaining high-value questions became configuration questions: which Overwatch functions are enabled, whether private cameras can participate in tracking, whether ALPR or AI detections can become tracking targets, what user permissions apply, what predicate is required before tracking begins and what the resulting audit logs preserve.
We understand much more now about what the architecture can do. The remaining local question is what Bend has configured it to do.
The oversight question is no longer “How many cameras?”
For years, a surveillance inventory could reasonably begin with a few basic questions: Where are the cameras? Who owns them? What do they record? How long is the footage retained? Who can view it?
Those questions remain necessary, but they are no longer sufficient. Once cameras and sensor data are connected through a system like Fusus, some of the most consequential capabilities exist between the devices.
The higher-value oversight questions are whether the system can recommend a next useful camera, whether a user can follow a person or vehicle across feeds, whether private cameras can participate, and whether ALPR, Body or Fleet information can appear in the same operational environment. Just as important are the rules around those actions: who can initiate them, what factual predicate or case information is required, what gets logged, and what survives after a tracking session ends.
These questions matter because integration removes friction.
An investigator using disconnected systems might need to identify a business, contact the owner, request footage, wait for a response, inspect the recording, determine where a subject went and repeat the process somewhere else.
Registration removes some friction. Live integration removes more. Overwatch removes more. AI-assisted search can remove more still. Predictive camera selection could remove another layer again.
Efficiency is the purpose of the technology, but efficiency is not privacy-neutral. The same architecture that makes it easier to rapidly locate a fleeing robbery suspect also lowers the technical cost of following someone whose movements should never have been monitored.
That is why an audit log is useful but insufficient. A log may tell the public who followed someone after the fact; the prior question is more important:
What had to be true before the network was allowed to follow that person at all?
The camera is no longer the whole surveillance system
Fusus did not invent surveillance cameras. Its more consequential contribution is architectural: treating cameras, dispatch calls, license-plate alerts, private video, drones, responder locations and other information as parts of a common operational environment.
Bend’s procurement history shows how such an environment can accumulate. Body cameras came first. Fleet and mobile ALPR followed. Drone capabilities followed. Then Fusus provided an interoperability layer capable of bringing categories of those systems together.
The drone program expanded. Axon acquired Fusus. Bend then folded the standalone Fusus relationship into a much larger Axon agreement.
Meanwhile, the Fusus patent portfolio moved from incident fusion toward camera-to-camera tracking, movement prediction and methods for reconstructing where a target may have gone—or where it may have come from.
Not every step in that progression is commercially confirmed, and not every commercially available function is enabled in Bend. That is precisely why procurement records alone are no longer sufficient.
A camera inventory tells the public where the government’s eyes are.
A contract inventory tells the public which products the government bought.
Neither one, by itself, tells us what those products can do together.
Fusus changes the oversight problem because the consequential unit is no longer necessarily the individual camera. It is the network—and the software rules that determine how that network can be used.