A data governance middleware layer for transaction processing: when a transaction arrives, the engine parses it into individual data elements, classifies each element by category — PII, financial, behavioral — selects the appropriate rules engine per category, generates encrypted secure versions, stores them on a distributed ledger, and sends decryption keys only to the specific nodes authorized for each data category. Each node sees only what it's permitted to see.
Financial transaction processing involves many nodes: fraud detection, compliance, settlement, analytics, customer service. Each node legitimately needs some subset of the data in every transaction. But traditional architectures broadcast the full transaction record to all processing nodes — every node can see everything, even elements it has no business purpose to access. PII reaches analytics nodes. Behavioral data reaches settlement nodes.
The engine intercepts incoming transaction data and runs it through a multi-stage pipeline. First, parse: extract individual data elements from the transaction record. Second, classify: assign each element to a data category (PII, financial, behavioral, etc.). Third, apply: select the rules engine specific to each category and execute it against each element.
The output is a set of encrypted "secure" versions of each data element, stored on a distributed ledger. The engine then generates targeted notifications: each authorized node receives a notification and the decryption key for the specific data categories it's authorized to access — and only those. A compliance node gets the compliance-category key. It does not receive the PII-category key. Data partitioning is enforced at the encryption layer, not just the policy layer.
The pipeline is defined in Claim 1 (apparatus) and Claim 11 (method). Three independent claims cover the core system, the method, and a CRM variant — giving the patent broad coverage across system architectures that implement the same data governance logic in different deployment contexts.
Claims 5, 8, 15, and 18 define the partitioning model: data categories are partitioned such that each target node only receives the decryption key for data elements within its specifically authorized category. The fraud detection node receives the fraud-signal key. It does not receive the PII key. The analytics node receives behavioral data access. It does not receive payment account details.
Claims 4, 7, 14, and 17 establish that the notification itself carries the decryption key — the key delivery is bundled with the notification, not managed separately. Claims 2–3 specify that distinct notifications are sent to different target nodes rather than a single broadcast, so each node receives a notification scoped precisely to its access rights.
Customer name, address, government ID. Key delivered only to compliance node and customer service node. Analytics, fraud, and settlement nodes receive no PII key.
Transaction amount, account numbers, balance signals. Key delivered to settlement, fraud detection, and compliance nodes. Analytics and behavioral nodes excluded.
Transaction patterns, velocity, geo-signals, time-of-day patterns. Key delivered to fraud detection and analytics nodes. Settlement and PII-focused nodes excluded.
Claims 9–10, 19: user privacy preferences registered in system. Routing decisions reflect current consent state. Preference changes propagate to key distribution for future transactions.
Select a scenario to trace the governance pipeline from transaction arrival to category-specific key delivery.
The consent management layer (Claims 9–10, 19) adds a two-way preference loop. Users register privacy preferences with the governance platform. These preferences are stored and associated with the user's data categories. Routing decisions for future transactions reflect the current preference state.
The behavioral incentive mechanic (Claims 10, 19) is notable: the system can identify preference changes that would benefit system operations and offer the user an incentive to modify their preference registration. The user sees the incentive offer, accepts or declines, and the system updates the registration based on the response. This isn't data sharing without consent — it's a structured mechanism for negotiated consent modification with explicit user action at each step.
Claim 9: users register specific privacy preferences per data category. "Do not share behavioral data with analytics" → behavioral category key not sent to analytics node.
Preference state is consulted on every transaction. Real-time routing decisions reflect current consent — not a historical snapshot from account setup.
Claim 10/19: system identifies beneficial preference changes, presents an incentive offer to the user (rate discount, feature unlock). User accepts or declines explicitly.
After user response, system updates preference registration. If accepted, routing expands accordingly. If declined, routing remains unchanged. User retains control at every step.
The governance engine pattern applies to any architecture where a transaction's data elements must be partitioned across a network of participants with asymmetric authorization levels. The encryption layer enforces what policy documents only describe.
One third-party citation found. Full list available on Google Patents.
US12386982B2 is one of two patents in this collection with a single inventor. The three independent claims cover the system from three different technical angles: Claim 1 (computing platform / apparatus), Claim 11 (method), and Claim 20 (CRM — a computer-readable medium variant). This triple-independent structure maximizes the defensive coverage of the core governance architecture.
Sole inventor. This patent was developed independently — a single architectural vision for privacy-by-encryption in transaction data routing, from conception through the 32-month examination process to grant in August 2025.
Computing platform with processor and memory. Covers hardware/software systems implementing the governance pipeline. Broadest system-level claim.
Method claims cover the process steps regardless of specific implementation. Broader than apparatus — applies to any system executing the governance sequence.
Computer-readable medium variant — covers distributed software implementations, cloud-native deployments, and containerized governance middleware.
Filed Nov 29, 2022 → granted Aug 12, 2025. Longest prosecution in Batch D — reflects the depth and novelty of the privacy architecture examined.