Investigation
Bend Privacy Alliance / Axon patents series, Part 1 of 11 · September 2026
Axon is building far more than body cameras. Its patents and current product documents describe an expanding ecosystem for license-plate search, camera fusion, movement tracking, AI-generated police reports, drone detection, evidence management, and real-time operations. The patents do not prove that every capability is deployed. They do show communities what may be possible inside platforms police departments are already buying.
A city can acquire a materially new surveillance capability without putting up a new camera pole.
Sometimes the change is a software setting, feature, or integration: a new search field appears, a retention setting changes, two databases begin sharing information, a camera feed becomes visible to another organization, or a body-camera transcript becomes input to a generative-AI police report. To the public, nothing obvious may have changed even though the system’s capabilities have changed substantially.
That is one reason I began looking at Axon’s patents.
Axon is still widely associated with Tasers and police body cameras, but the company now operates across a much larger public-safety technology stack: mobile license-plate recognition, real-time crime centers, fixed cameras, evidence management, drones, automated transcription, police records, generative AI, and — through its acquisition of Dedrone — drone detection and airspace awareness.
Public oversight often examines those products one at a time.
A city considers body cameras. Later, it considers license-plate readers.
Then a camera-integration platform. Then a drone program.
Then artificial intelligence. Each purchase may be justified for a legitimate purpose. But the harder civil-liberties question is what happens when those systems begin to share data, enrich one another’s records, and operate inside the same software environment.
Patents offer one imperfect but useful window into that question. A patent can describe something that is never commercialized. A patent application can be broader than a final product. A capability described by one company acquired by Axon may never be integrated with another Axon system.
So this investigation does not treat patents as proof of deployment.
Instead, it asks three separate questions:
- What technical capabilities do Axon and acquired-company patents describe?
- Which of those capabilities are corroborated by current Axon product documentation?
- Which are actually documented in use by a real police department?
Bend, Oregon — where I live and conduct much of my local surveillance research — provides a useful case study for the third question.
Read together, the patent record, product documentation, and local procurement history reveal a recurring technological progression:
capture → identify → search → track → predict → combine → preserve as evidence → generate a report
No single document proves that Axon operates that entire progression as one autonomous system.
But significant parts of the chain already exist as current products, and several of the surrounding platform layers are already deployed in Bend.
The policy question is therefore not simply, What has police purchased?
The policy question is increasingly what new capabilities can be activated inside technology government already owns, and what public process applies when that happens.
How to read this investigation
PATENT ≠ PRODUCT ≠ DEPLOYMENT
A patent shows what an inventor sought to protect. Product documentation shows what Axon currently offers or documents. Agency records show what a particular police department actually has or uses. This article keeps those categories separate.
This research separates four different kinds of evidence. Patent disclosure means a patent or patent application describes a technical capability.
Product evidence means Axon’s current documentation confirms that a capability exists in a commercial product.
Deployment evidence means a contract, government record, policy, audit log, or other source establishes that a particular agency has actually obtained or used the capability.
Inference means that two pieces of technology appear technically capable of working together, but that integration has not been independently established.
Those distinctions are important because a sentence that begins, “A Fusus patent application describes…” should not silently become, “Police are doing this.”
Likewise, the fact that Axon sells a feature does not establish that every agency using the surrounding platform has enabled it.
That evidentiary boundary runs through everything that follows.
From plate readers to searchable movement histories
Automatic license-plate readers are a useful place to begin because the technical progression is unusually visible.
Axon-assigned patents describe a series of engineering improvements intended to make mobile plate reading more reliable.
Earlier patents in the family address the practical problem of capturing readable plates from a moving patrol vehicle. Later filings go well beyond ordinary camera cleanup. US11532170B2, for example, describes detecting the same plate in multiple frames, aligning those plate images, geometrically correcting them through scaling, warping, or rotation, and then applying temporal noise filtering so the resulting image is more likely to produce a successful OCR read.
That is worth dwelling on because it changes what “the plate image” can mean. The relevant image may not simply be one untouched frame from the camera; the patent describes a process in which multiple observations of the same plate are mathematically aligned and transformed to improve recognition. That does not establish how every current Fleet 3 read is produced, but it raises a straightforward evidentiary question: when an enhanced or consolidated plate image is shown to an officer, analyst, court, or defense attorney, is the original source imagery preserved alongside it?
A later patent, US11978260B2, describes a two-stage computer-vision process. The system can begin with a high-resolution captured image, scale it down to locate the plate more efficiently, and then return to higher-resolution imagery to perform recognition. One dependent claim specifically identifies an object-detection model trained to detect the shape of a license plate. The patent also claims that image generation, plate detection, and plate reading can occur locally at a vehicle-mounted imaging device in under one second.
That kind of local, rapid processing helps explain how mobile ALPR can operate at patrol speed without waiting for a remote server before producing a result.
Another Axon patent, US12541984B2, issued in February 2026, addresses something even more mundane: monitoring whether an LPR system’s performance has degraded because of obstruction or other quality problems.
These are not inherently sinister inventions. They solve real engineering problems.
But the civil-liberties significance comes from scale. Every improvement that makes a plate reader less likely to miss a passing vehicle can increase the number of ordinary motorists whose movements become machine-readable records.
And current Axon products go well beyond simply checking whether a plate appears on a stolen-vehicle list.
Axon’s current Fusus ALPR Search documentation allows investigators to search using:
- full or partial plate numbers;
- wildcards;
- vehicle color;
- make;
- body type;
- additional AI-detected characteristics such as roof racks or bumper stickers.
The system lets users adjust confidence thresholds for these AI-detected attributes and displays confidence scores in results.
A plate number is not always required. The same interface can show the location of a detection on a map and display previous reads associated with a plate over periods such as 7, 14, or 30 days, subject to the agency’s retention period.
Axon also documents the ability to search detections drawn from different ALPR sources, including Fleet 3, fixed Axon Outpost cameras, third-party “Works with Axon” systems, Vigilant, Flock, Jenoptik, and other connected sources.
And partner agencies can establish sharing relationships that allow authorized searches across one another’s ALPR data.
That changes the nature of the system. A plate reader at one intersection answers:
Was this vehicle here?
A searchable network can support a different question: Where else has this vehicle appeared?
And if search criteria can begin with vehicle characteristics rather than an exact plate, the investigative starting point can become broader still.
Axon also documents audit controls: search reasons, offense categories, case-number configuration, confidence thresholds, and activity reports.
Those safeguards are meaningful, but they also make local configuration part of the policy question: what has the agency actually enabled, required, or allowed?
The product may support strict case-number requirements, narrow sharing, short retention, and robust auditing.
Or the agency may configure those options differently. For cloud-based policing systems, configuration itself increasingly functions as policy.
A plate is a point. A connected camera network can become a path.
The next step in the patent record is more consequential.
Fusus — the real-time crime-center company Axon acquired — has filed patent applications describing systems that do more than display camera feeds.
One application, US20240062395A1, describes a crime-center system for video-based object tracking using an active camera and a set of “next-up” cameras.
In plain English, the architecture begins with a person or vehicle seen by one camera.
The system can use information such as the object’s direction and speed to determine which nearby cameras are likely to see it next.
It can then assist in reacquiring the object as it moves.
The basic concept is easy to understand: Camera A sees an object.
The system knows where surrounding cameras are located and where they point.
Direction and speed narrow the likely route. The system identifies which camera is likely to see the object next.
The search continues. That is different in practice from manually opening one camera feed at a time.
And the patent material is not limited to cars.
It describes tracked objects that can include people. Current Axon documentation confirms important pieces of the surrounding architecture. Fusus cameras can be geospatially mapped, assigned viewing directions, grouped, and integrated into a common operational environment. Axon also documents camera sharing between organizations under configured permissions.
A separate Fusus patent family, US11443613B2 / US20220076556A1, addresses another form of conditional access. It describes a system in which a private camera feed can remain inaccessible during ordinary conditions and then become available when a predefined emergency condition occurs. The issued patent expressly covers the emergency condition being detected automatically rather than requiring a person to grant access in the moment. The specification gives access-control events and weapons-detection events as examples.
That is a different model from a camera that is continuously visible to police. It is also different from a purely manual emergency-share button. The significance is that the access boundary itself can become software-defined: a privately controlled feed can remain unavailable until the system decides that a triggering condition has been met.
Current Bend records establish a pathway for participating businesses to provide conditional Fusus camera access, but they do not establish that Bend uses this specific patented automatic-trigger mechanism.
What current product documentation does not yet establish is equally important.
I have not found a current Axon product guide explicitly promising that every Fusus customer can automatically predict which camera a particular person will appear on next and follow them across a city.
That more advanced claim remains a patent disclosure rather than an established current product fact, which is exactly why the distinction between patents and deployment matters here.
The patent record tells communities what questions they may need to ask before such a feature appears quietly as a software update or subscription option inside infrastructure that is already deployed.
From tracking to prediction
A later Fusus patent application pushes the concept further.
WO2025128824A1, “Methods and systems for video-based object tracking using isochrones,” describes using time, location, speed, direction, and geographic constraints to estimate where an object could plausibly travel.
An “isochrone” is essentially a reachable area. If a vehicle is observed traveling north at a particular time, the system can calculate the region it could plausibly reach within a given period and identify cameras in that area.
That makes searches more efficient. But the patent also describes doing this in both directions in time.
In other words, the system can ask not only:
Where could this object go next?
but also: Where might it have come from?
That could turn camera infrastructure into a movement-reconstruction tool.
One dependent claim goes further still, describing use of a large language model to transcribe and analyze an emergency call to identify a relevant time and location that can seed the tracking process.
Conceptually, that creates a possible chain like this: 911 call
→ possible prior or future locations are predicted
This is still only a patent application; it does not establish that Axon currently operates the full workflow as a deployed autonomous product. But it describes an architecture worth debating before it becomes ordinary infrastructure.
The same architecture can follow people, not just plates
License-plate readers identify vehicles through a highly standardized identifier.
Cross-camera computer vision does not necessarily need that identifier.
Patent disclosures in the Fusus tracking family discuss machine-derived characteristics that can help reacquire an object in another video feed.
For vehicles, this may include appearance or learned visual features.
For people, the patent specification describes attributes that can include gender, clothing, hats, clothing colors, and bags or backpacks. The same patent family describes an AI-assisted reacquisition process that can analyze nearby camera feeds and present possible matches when a tracked object is lost from the expected path.
That is a specification-level disclosure, not evidence that every current Fusus customer has enabled AI-assisted person reacquisition or that any particular agency uses it.
The more important point is that a system does not necessarily need to know someone’s legal identity to maintain a persistent operational identity.
“Blue jacket, black backpack, traveling east, same visual feature representation” may be enough for software to continue asking whether the same person appears elsewhere.
That is an important conceptual change. Traditional identification asks who a person is. Persistent machine tracking can work with a different question: whether the person seen here is the same person seen somewhere else.
The appearance-based reacquisition capability described above comes from the patent specification, not from a Bend deployment record. That distinction is essential.
When different surveillance systems become one interface
If the patent record shows technical direction, current product documentation shows that some important integration is already here.
Axon describes Fusus as a central environment capable of combining multiple kinds of information.
Its current materials describe integrations involving video, license-plate readers, sensors, drones, access-control systems, and public- and private-sector camera infrastructure.
Axon also documents ALPR alerts that can link an operator directly to the camera associated with the event.
For large events, Axon’s event-protection documentation describes Fusus as a shared operational map incorporating live video, sensors, 911/CAD information, drone detections, and officer locations.
This is where the privacy implications become systemic. A camera registry may sound like one thing.
An ALPR search system may sound like another. A drone-detection platform may sound unrelated.
An officer-location system may have an entirely different justification.
But once those systems share an operational interface, their combined capabilities are different from the sum of their parts.
The oversight question therefore has to expand beyond what a product does on its own to what other systems it can query, trigger, display, enrich, or feed.
When surveillance data becomes evidence
The next transition in Axon’s portfolio is from observing an event to turning it into an official record.
Axon has long operated evidence-management systems. But its patent history shows increasing automation of the process by which unstructured recordings become structured information.
US11373035B1, “Systems and methods for structured report generation,” describes an earlier Axon architecture for extracting report-relevant information from recorded evidence and using it to help populate structured reports.
That can include transcription, OCR, extraction of information about people and vehicles, object detection, and links back to source material.
The underlying idea is significant because a body-camera recording can function as more than a video file.
It can become machine-readable input. Information can be extracted, categorized, searched, summarized, and incorporated into downstream records.
This is the technical lineage that helps explain the next step: Draft One.
When recorded evidence becomes an AI-written police narrative
Draft One is Axon’s generative-AI police-report product. A current Axon patent application, WO2025106596A1, “Automatically generating a report using audio data,” describes a system that combines an incident transcript with predetermined report-generation instructions and sends that information to a generative computing system.
The report instructions can concern things such as narrative style, perspective, ordering, and report format.
The patent also raises a less obvious issue: sample reports. Claim 6 allows a sample police report to be selected according to incident type and included in the model prompt, and the specification says different agencies can maintain their own collections of sample reports.
I have found no evidence that current Draft One actually uses this feature. That limitation is important. But if an agency-specific sample-report system were implemented, it would raise a different set of questions from ordinary hallucination or transcript-error concerns. Historical agency writing patterns could potentially influence generated style, terminology, emphasis, or framing. A system trained or prompted to imitate “how this department writes burglary reports” could reproduce not only formatting conventions but also recurring narrative habits.
That can be more than summarization, because a police report transforms a messy real-world event into an authoritative institutional narrative.
People interrupt one another. Witnesses disagree.
Audio is unclear. Officers arrive at different times.
Some facts are observed directly. Others are reported by someone else.
A generative system has to transform that disorder into prose according to its instructions and model behavior.
Even though the model does not make human judgments, the resulting narrative still reflects computational choices about sequence, inclusion, omission, perspective, and wording.
That makes provenance especially important. Can someone reviewing the final report reconstruct where each important statement came from?
The patent describes mechanisms for linking report information back to source material.
Axon’s current Draft One documentation also makes important safeguards visible.
On its Draft One responsibility page, Axon warns that transcripts and AI output can contain errors and that users are responsible for reviewing generated material.
It offers an “Obvious Error Mode” that can intentionally insert conspicuous errors into a draft so the officer must engage with the text before finalization.
And Axon now offers a configurable original-draft retention feature for retaining the original, unedited AI-generated draft.
That last feature is especially important. Axon says original-draft retention is off by default.
Agencies may choose whether to retain those drafts and how they are deleted.
The system also records audit events related to Draft One use and retention activity.
Those are meaningful safeguards, but they also create concrete public-policy questions:
- Has the agency turned original-draft retention on?
- How long are drafts retained?
- Are officer edits preserved as versions?
- Can prosecutors or defense attorneys obtain the original AI draft?
- Is the model/version used to generate the report logged?
- Can a disputed sentence be traced back to the exact transcript or source audio?
- What happens when the transcript itself is wrong?
At that point, AI governance becomes part of evidence governance.
AI-generated evidence-related material should have a chain of provenance just as physical evidence has a chain of custody.
From a drone in the sky to a location on the ground
Axon’s acquisition of Dedrone adds another layer: airspace detection and tracking.
Dedrone patents now assigned to Axon describe RF, radar, and multi-sensor architectures for identifying and tracking unmanned aircraft.
US12135382B2 concerns detection of unmanned aerial vehicles through radio-frequency analysis.
The patent explains a particularly important problem: radio signals may come from a drone or its controller, and reflections or obstructions can make the apparent origin of a signal misleading.
That technical detail is important because current Axon materials describe capabilities more sensitive than merely detecting that a drone exists.
Axon’s current Dedrone materials describe drone detection, tracking, and pilot geolocation.
Axon’s event-protection documentation also states that Dedrone can push drone flight paths and potential pilot locations directly into Fusus.
Notice the wording: potential pilot locations. Elsewhere Axon uses language such as “likely launch location.”
Those qualifiers matter. A responder looking at a dot on a map needs to know whether that point represents:
- a directly broadcast Remote ID location;
- an RF-derived estimate;
- triangulation;
- a likely launch origin;
- or some other inference.
An inferred location can be operationally useful and still be wrong.
The patent itself acknowledges technical conditions that can make RF origin difficult to determine.
That suggests a general rule that extends well beyond drones:
An inferred location should not be presented with the same apparent certainty as a directly measured location.
Systems presenting location inferences should preserve where a location came from, when it was calculated, what method produced it, and what uncertainty accompanied it.
Bend, Oregon: what is actually deployed?
BEND IS A CASE STUDY, NOT A CLAIM THAT EVERY FEATURE IS ACTIVE
Bend is useful here because several Axon platform layers are locally documented. That does not mean Bend has activated every current Axon feature or every capability described in the patent portfolio.
This is where the distinction between patent, product, and deployment becomes concrete.
Bend’s Axon stack developed in layers. An October 2, 2024 City Council issue summary says the City had separately purchased Axon body cameras in 2021, Fleet cameras in 2022, Fusus software and hardware in 2023, and additional Axon drone software licenses in 2024. The same 2024 package folded much of that previously separate software into Axon’s Officer Safety Plan 10 Premium bundle.
The City’s 2022 Axon Fleet quote is more specific than the agenda summary: it included 65 Fleet 3 Basic licenses and 65 “FLEET 3, ALPR LICENSE, 1 CAMERA” licenses, with the ALPR software term beginning August 1, 2023.
Bend also operates a substantial police drone program. The City’s current UAS page says the department uses 15 drones and stores UAS evidence through Evidence.com.
The City has also documented Fusus as part of its local camera-integration infrastructure. A Bend Police quarterly report says participating businesses can purchase a FususCORE device that can provide Bend Police conditional access to a camera feed during an emergency.
Fixed/stationary ALPR is different. A May 1, 2026 City Manager report said the department planned to work with Axon to evaluate two demonstration units and pursue phased fixed-camera installation at city entry and exit points. In this final source check, I did not locate a newer primary City record establishing that fixed Axon ALPR had actually been activated.
Ryan Haas reported for The Western Edge on Bend Police’s use of Draft One, providing the reporting basis for treating Draft One as an operational local deployment rather than merely an available Axon product. Our review still does not establish that Bend uses everything described elsewhere in Axon’s patent portfolio.
We have not established Bend use of:
- Fusus isochrone tracking;
- automatic predictive next-camera tracking;
- generalized person re-identification;
- Dedrone RF/radar drone detection;
- Dedrone pilot geolocation.
Those remain patent-level or broader product-level capabilities unless and until local records establish otherwise.
The harder governance question is what happens when substantively new software capability is added to an already-deployed platform.
Draft One exposes a procurement blind spot
Bend’s Draft One deployment illustrates the problem particularly well.
Bend’s October 2024 Axon OSP10 Premium quote included broad infrastructure: Axon Records, Unlimited Auto-Transcribe, Respond Plus, FususONE, Evidence storage, API services, and other products.
But the contract we reviewed does not name Draft One.
Independent reporting by Ryan Haas at The Western Edge supports that Bend Police began using Draft One.
That leaves a key question unanswered: What record actually provisioned the generative-AI capability?
Was it:
- a zero-dollar quote?
- a pilot?
- a free trial?
- an add-on?
- an Axon promotional offer?
- a later order form?
- an administrative tenant activation?
The answer matters because public oversight often focuses on purchases, while cloud software can change the model underneath that oversight.
A department may already possess much of the hardware, account structure, evidence platform, APIs, and user infrastructure needed to activate a materially new capability.
If the new feature costs little or nothing during a pilot, traditional procurement triggers may provide less public visibility.
That raises a governance question far larger than Draft One:
Should public review attach only to the purchase of technology, or also to the activation of new surveillance and AI capabilities inside technology government already owns?
Configuration is becoming policy
CONFIGURATION IS POLICY
Retention periods, sharing partners, confidence thresholds, permissions, AI-draft preservation, and feature flags can change what the same product does in practice from one agency to another.
Modern surveillance systems are governed not only by ordinance language and contracts, but also by settings. That can sound abstract until you look at how much policy is embedded in the configuration of systems already discussed in this article.
Start with ALPR. A department may license the same underlying search platform as another agency while making very different choices about how it can be used. Depending on the product and local setup, configuration can affect things such as:
- how far back users can search;
- whether partner-agency data appears in results;
- whether vehicle characteristics can be used as search terms;
- what confidence thresholds are shown or accepted;
- whether a case number or offense category is required;
- who can export results.
Move one step downstream to Draft One and the same issue appears in a different form. The central question is no longer only what the AI can generate, but what the agency preserves around that generation. Configuration can affect:
- whether the original AI-generated draft is retained;
- how long it is retained;
- which users can access Draft One;
- what audit records are available;
- what source evidence is available during review.
Then consider a real-time operations platform such as Fusus. Here, configuration can determine the boundaries between systems and organizations:
- which cameras are visible;
- whether a private camera is available continuously or only under certain conditions;
- which organizations can receive shared access;
- which user roles can view live video or playback;
- what new analytics or integrations are enabled later.
These are not minor administrative choices. Two police departments can license the same product and still operate meaningfully different surveillance environments because their retention rules, sharing relationships, permissions, and enabled features differ.
That means policymakers should start asking for something procurement documents rarely provide: configuration transparency. Not passwords or security secrets, but records sufficient to understand which capabilities are enabled, who may use them, how long resulting data is retained, which outside organizations receive access, and what audit controls exist.
What changes when these systems are combined
This is where the progression introduced near the beginning becomes useful. So far, each capability has been easier to understand in isolation: ALPR finds and searches vehicles; camera systems can follow objects across space; evidence systems turn recordings into structured data; Draft One can turn transcripts and other evidence into report prose; Dedrone adds another source of location and tracking information.
The more difficult question is what happens when those stages begin to connect.
camera / body camera / ALPR / private video / drone / sensor / 911 event
→ object or event identification
→ location
→ search across connected sources
→ movement reconstruction or prediction
→ real-time operational display
→ evidence creation
→ transcription
→ AI-generated report
That is not a claim that Axon currently runs every step automatically as one unified system. It is a way to see how capabilities that are often purchased and governed separately can become part of the same operational environment.
The civil-liberties concerns described throughout the article follow from that connection. Data collected for one purpose can acquire new uses later. Fleeting observations can become searchable history. Machine inferences can lose their uncertainty as they move into another system. Context can disappear when information is shared between agencies or transformed into evidence and report prose.
The core issue is not simply that police have always observed people, vehicles, and events. It is that software can make those observations persistent, searchable, combinable, and reusable at a scale that changes their practical effect.
At that point, the most useful oversight questions are also the simplest: which capabilities are actually enabled, who can access or share the resulting data, how long the information is kept, and whether the agency can later reconstruct how an important conclusion was reached.
The oversight question is changing
For years, technology oversight was relatively tangible. A city bought cameras, installed them in identifiable places, approved a contract, and could point to the hardware being added. The public debate naturally focused on how many devices were being purchased, where they would go, and what they would cost.
Cloud-connected policing systems make that model harder to rely on. The same hardware can behave differently a year later because a new search field has been added, a sharing relationship has been enabled, a retention period has changed, or an AI feature has been switched on. A camera feed that once stayed inside one organization can become available to another. A transcript that once served mainly as a reference can become input to a generative police report. None of those changes requires a new camera pole or an obvious piece of equipment appearing on the street.
This is the point I keep coming back to after looking through the patents, product documentation, and Bend records: procurement is no longer the only moment when meaningful oversight is needed. Feature activation, configuration changes, integrations, and major software updates can alter what a system is capable of doing even when the underlying contract or hardware looks familiar.
That does not mean every new feature is dangerous, or that any of the technologies discussed here will inevitably be abused. It means capability and authority are separate questions. A company may be able to build a system, and a police department may be able to turn on a feature, without having answered the harder public question of whether government should use that capability at all — and, if so, under what limits.
Patents alone cannot tell us what a police department is doing today. What they can do is give us an earlier look at where the technology may be heading, while there is still time to decide what rules, transparency, and public review should come first.
The public should not have to wait for a new camera pole to learn that the capabilities of a surveillance system have changed in a significant way.