A decentralized security framework where any network node can validate a data payload locally — using a digital certificate, no central authority required. Multi-tier masking routes different views of the same payload to different nodes based on their geographic location, security clearance level, or network position.
Standard PKI and certificate-based authentication models depend on a central certificate authority (CA) or validation server. Every node that receives a payload must query the CA to verify the certificate. At scale, this creates a bottleneck: network congestion as all verification traffic passes through one point, and a single-point-of-failure that, if disrupted, breaks authentication for every node simultaneously.
The authenticating node computes a security clearance for the incoming data payload, then embeds a digital certificate directly into the payload before forwarding. Every receiving node along the network path can validate that certificate using a locally accessible cryptographic key — no query back to any central authority needed. The certificate travels with the data.
Multi-tier masking (Claims 2–4) layers access control on top: before forwarding, a node can mask portions of the payload based on the receiving node's geo-location, security clearance level, or network equipment security level. Different nodes see different views of the same payload — routed by their trust context, not by the sender's manual configuration.
Claim 7 introduces the asymmetric key architecture: trusted nodes hold a private key (decrypts the first information set), untrusted nodes hold a public key (decrypts the second information set). The same encrypted payload reaches all nodes — but each node can only decrypt the portion it's authorized for. No conditional routing logic needed at the sending node.
The certificate replacement mechanism (Claim 1) extends this: as the payload traverses the network, each receiving node can replace the incoming certificate with a newly generated one before forwarding to the next node — maintaining a fresh, locally-signed certificate at each hop rather than carrying the original certificate all the way to the destination.
The masking system (Claims 2–4) operates on three independent dimensions. Claim 2: geo-location — a node in a restricted geographic region receives a masked view of the payload. Claim 3: security clearance level — nodes with lower clearance receive masked versions of sensitive fields. Claim 4: network position — if the receiving node is connected via unsecured equipment or infrastructure, masking is applied.
These three signals can be applied independently or in combination. A geo-restricted, low-clearance node connected via unsecured equipment would receive a payload masked on all three dimensions. A high-clearance, geo-local, secure-network node would receive the full unmasked payload. The masking logic runs at the forwarding node — not at the originating node — enabling dynamic, context-aware access control at each hop.
Forwarding node checks geographic location of the requesting/receiving node. Nodes in restricted regions receive masked payload — sensitive fields redacted before transmission.
Forwarding node checks security clearance level assigned to the receiving node. Low-clearance nodes receive only the fields they're authorized to see.
If receiving node is connected via insecure equipment or network path, masking is applied regardless of clearance level — defensive posture for unsecured infrastructure.
Trusted nodes: private key decrypts first information set (sensitive). Untrusted nodes: public key decrypts second information set (non-sensitive). Same encrypted payload — different decryption access.
Select a node type below to trace what it receives, what it can decrypt, and how it handles the payload before forwarding.
Claim 9 introduces the trust cascade mechanism: once a configurable threshold number of nodes has successfully confirmed the digital certificate, subsequent nodes in the chain forward the payload without performing the confirmation check again. This prevents the validation overhead from scaling linearly with the number of nodes in the network path.
Claim 10 adds a time-based validity window: the certificate is only valid if it was signed within a target time window — a TTL (time-to-live) mechanism that prevents stale certificates from being replayed indefinitely. Claim 11 extends this to a geographic validity window: the certificate is only valid if signed within a target geographic location, limiting certificate portability across regions.
After N nodes confirm the certificate, subsequent nodes forward without re-checking. Configurable threshold balances security depth against validation overhead.
Claim 8: if the second node cannot confirm the certificate was signed by the first node, it independently authenticates the payload before forwarding — no silent pass-through.
Claim 10: certificate must have been signed within a target time window. Expired certificates rejected — prevents replay attacks using old valid certificates.
Claim 11: certificate valid only within a target geographic location. A certificate signed in Region A cannot be used to authenticate a payload forwarded from Region B.
The framework's value is highest in environments where central authority queries are impractical: high-latency networks, air-gapped edge deployments, high-throughput data pipelines where every round-trip to a CA is a bottleneck, or distributed ledger architectures where each participating node needs independent verification capability.
Cited by Oracle International Corporation in a 2025 patent on facilitating secured access to protected resources hosted in one cloud from another — directly validating the cross-boundary, certificate-based decentralized authentication model.
US12120104B2 is one of two patents in this portfolio where Siten Sanghvi is the sole inventor (alongside US12386982B2). The 15 claims cover the architecture from two independent angles: Claim 1 is an apparatus claim covering the routing framework as a system of nodes; Claim 7 is a method claim covering the same architecture as a sequence of operations.
The two independent claims share the same inventive core — local certificate validation — but claim it from different directions, providing protection against both system-level and method-level infringement. The 13 dependent claims build the full multi-tier masking system, trust cascade, time-based TTL, geographic TTL, and data-stripping mechanisms on top of that core.
Routing framework: authenticating node computes clearance → adds certificate → first receiving node validates locally → generates new certificate → forwards to second receiving node.
Same architecture as a method: authenticate → generate certificate → package into container → forward → confirm signature at each node → forward. Asymmetric key split for trusted vs. untrusted nodes.
Three masking dimensions (geo, clearance, network position) + asymmetric key configuration. Built on top of Claim 1's apparatus foundation.
Independent fallback auth, threshold-based cascade, timestamp TTL, geographic TTL, data removal for untrusted nodes, identity-based masking decisions.