Derivative works — US Patent 10355863

Defensive Disclosure: System and Method for Authenticating Electronic Content Using Algorithmically Generated Visual Markers

Publication Date: May 10, 2026

Abstract: This disclosure describes derivative methods and systems for authenticating electronic content. The core concept involves the real-time server-side generation of a unique, algorithmically-derived visual marker that is embedded into electronic data before transmission to a client. These methods extend the concept of using fractals for authentication, as described in US 10,355,863, to include alternative generative algorithms, applications in diverse technological domains such as autonomous vehicles and industrial IoT, and integration with emerging technologies like blockchain and artificial intelligence. The disclosure also covers low-power operational modes and combinations with open-source standards to provide a comprehensive body of prior art, thereby dedicating these improvements to the public domain.

Derivative Variations on Core Claim of US 10,355,863

The following disclosures expand upon the method of real-time, server-side generation and insertion of an authenticity marker into electronic data.

1. Algorithmic and Component Substitution

1.1. Cellular Automata-Based Markers

Enabling Description: This method replaces the fractal generation algorithm with one based on cellular automata (CA). Upon receiving a data request, the server generates a unique seed value derived from session-specific information (e.g., User ID, timestamp, IP address) and a server-side secret. This seed is used to initialize the first-generation state of a 1D or 2D cellular automaton, such as Wolfram's Rule 30 or Conway's Game of Life. The server computes a predetermined number of generations (e.g., 256 generations for a 256x256 pixel image). The final state of the automaton is rendered as a bitmap image, where each cell's state (e.g., alive/dead or a specific value) is mapped to a color. This bitmap serves as the unique authenticity marker and is embedded into the requested electronic content. The non-linear and chaotic nature of certain CA rules makes the resulting pattern highly sensitive to the initial seed, ensuring uniqueness and difficulty of forgery.

Mermaid Diagram:

sequenceDiagram
    participant Client
    participant WebServer
    participant CAServer as Auth (Cellular Automaton) Server

    Client->>WebServer: Request for data (e.g., GET /page)
    WebServer->>CAServer: Request authentication marker
    CAServer-->>CAServer: Generate seed (SessionID + Timestamp + Secret)
    CAServer-->>CAServer: Initialize CA with seed
    CAServer-->>CAServer: Compute N generations
    CAServer-->>CAServer: Render final CA state to bitmap
    CAServer->>WebServer: Return CA-based marker image
    WebServer->>WebServer: Retrieve requested data
    WebServer->>WebServer: Embed CA marker into data
    WebServer->>Client: Return data with embedded marker

1.2. L-System-Based Botanical Markers

Enabling Description: This variation utilizes Lindenmayer systems (L-systems) to generate unique, organic, or plant-like visual markers. An L-system is a parallel rewriting system defined by an alphabet, an initial string (axiom), and a set of production rules. The server stores a set of base L-system rules for generating various botanical structures. For each authentication request, the server dynamically modifies these rules or the initial axiom based on user-specific data (e.g., last transaction amount, account creation date). For instance, the turning angle used in the graphical interpretation of the L-system string could be a function of the timestamp's millisecond value. The server iterates the L-system for a fixed number of steps, generating a long string, which is then interpreted by a turtle graphics engine to draw a 2D or 3D image. This rendered image is the authenticity marker.

Mermaid Diagram:

flowchart TD
    A[Start: Data Request Received] --> B{Generate Session Seed};
    B --> C[Select Base L-System Rules];
    B --> D{Dynamically Modify Rules/Axiom using Seed};
    C & D --> E[Iterate L-System for N steps];
    E --> F[Generate Instruction String];
    F --> G[Interpret String via Turtle Graphics];
    G --> H[Render Botanical Image Marker];
    A --> I[Retrieve Requested Data];
    H & I --> J{Embed Marker into Data};
    J --> K[End: Return Formatted Data to Client];

2. Operational Parameter Expansion

2.1. Micro-Markers for High-Frequency Data Streams

Enabling Description: To authenticate high-frequency data streams (e.g., financial market data, live video feeds at >60 FPS), full fractal rendering per packet is computationally infeasible. This method generates a low-complexity "micro-marker." The generating algorithm (e.g., a Mandelbrot set) is parameterized with a drastically reduced iteration count (e.g., 5-10 iterations instead of hundreds) and rendered to a small resolution (e.g., 16x16 pixels). This micro-marker is generated for every k-th data packet or video frame. The seed for the marker is derived from a hash of the payload of the preceding k-1 packets. The client application buffers the stream, verifies the micro-marker for each k-th packet against its own calculation using the previous packets' data, and only then displays the content. This provides rolling authentication of the stream's integrity and origin with minimal latency.

Mermaid Diagram:

stateDiagram-v2
    [*] --> Streaming
    Streaming --> Generating: Every k-th packet
    Generating --> Embedding: Marker complete
    Embedding --> Streaming: Packet sent

    state Generating {
        direction LR
        [*] --> HashPayloads
        HashPayloads --> GenerateSeed: Hash of packets (n-k+1 to n-1)
        GenerateSeed --> RenderMicroMarker: Low-iteration fractal (16x16 px)
        RenderMicroMarker --> [*]
    }

2.2. Low-Bandwidth Asynchronous Authentication via Local Rendering

Enabling Description: In bandwidth-constrained environments like remote IoT sensor networks, transmitting a rendered image marker is inefficient. This method minimizes data transmission by sending only the instructions to generate the marker. The server, upon request, generates a unique seed and selects a specific fractal algorithm identifier. It transmits this compact data packet (e.g., {algo_id: "JuliaSet", seed: "0xABC123"}) to the client device. The client device must have a trusted execution environment (TEE) or a secure enclave containing the corresponding library of authentication algorithms. The TEE receives the parameters, renders the fractal image locally in a secure memory space, and displays it to the user or uses it for machine-to-machine verification. The server never sends the image, only the parameters, reducing the payload by orders of magnitude.

Mermaid Diagram:

sequenceDiagram
    participant ClientDevice
    participant TEE as Trusted Execution Environment
    participant Server

    ClientDevice->>Server: Request for authenticated data
    Server->>Server: Generate authentication params (algo_id, seed)
    Server->>ClientDevice: Send data + auth params
    ClientDevice->>TEE: Pass auth params for rendering
    TEE->>TEE: Select algorithm by algo_id
    TEE->>TEE: Generate marker using seed
    TEE->>ClientDevice: Return rendered marker image
    ClientDevice->>ClientDevice: Display data with locally rendered marker

3. Cross-Domain Application

3.1. AgTech: Verifying Drone-Based Crop Imagery

Enabling Description: In precision agriculture, a server processes aerial images from a fleet of drones to create crop health maps. To ensure data integrity and prevent injection of false imagery, the server embeds a unique visual marker into each processed image tile. The marker is an algorithmically generated pattern (e.g., a fractal) whose seed is a cryptographic hash of the drone's unique hardware ID, the tile's GPS coordinates (to micro-degree precision), and the capture timestamp from the image's EXIF data. This watermark authenticates the image's origin, location, and time. An agronomist viewing the aggregated map can have high confidence that the data has not been tampered with or sourced from an unauthorized device.

Mermaid Diagram:

flowchart TD
    A[Drone captures image] --> B[Image uploaded to server];
    B --> C{Extract EXIF Data: DroneID, GPS, Timestamp};
    C --> D[Compute Hash of EXIF data];
    D --> E{Seed fractal algorithm with hash};
    E --> F[Generate unique fractal watermark];
    B --> G[Process image tile];
    F & G --> H{Embed watermark into tile};
    H --> I[Store authenticated tile in database];

3.2. Autonomous Vehicles: V2V Communication Authentication

Enabling Description: To prevent spoofing of safety-critical messages (e.g., "hard braking ahead") in Vehicle-to-Vehicle (V2V) communication, a visual authentication marker is used for in-car display. When a vehicle (Car A) broadcasts a critical message, its onboard authentication server generates a fractal marker seeded with the message type, timestamp, and Car A's private key signature. A receiving vehicle (Car B) verifies the signature. If valid, Car B's system renders the fractal and displays it on the dashboard UI next to the alert. The fractal's pattern is unique to Car A. If Car B receives multiple alerts from Car A, the consistent visual marker assures the driver that the alerts originate from the same trusted source, preventing confusion from a potential spoofing attack trying to mimic alerts.

Mermaid Diagram:

sequenceDiagram
    participant Car_A as Vehicle A
    participant Car_B as Vehicle B
    participant Driver_B as Driver of B

    Car_A->>Car_A: Generates safety message (e.g., "Hard Brake")
    Car_A->>Car_A: Generates fractal marker (seed: message + signature)
    Car_A-->>Car_B: Broadcasts message + marker
    Car_B->>Car_B: Verifies message signature
    alt Signature is Valid
        Car_B->>Car_B: Renders fractal from marker data
        Car_B->>Driver_B: Display alert on dashboard with fractal
    else Signature is Invalid
        Car_B->>Driver_B: Discard message or flag as untrusted
    end

4. Integration with Emerging Technology

4.1. AI-Generated Latent Space Markers (GANs)

Enabling Description: This method leverages a Generative Adversarial Network (GAN) for marker creation, moving beyond deterministic algorithms like fractals. The authentication server hosts a pre-trained GAN generator model. Upon a data request, the server generates a high-dimensional vector in the GAN's latent space. This vector is seeded by a hash of session data and a server secret. The generator model processes this vector to produce a complex, unique, and non-repeating image that is stylistically consistent but entirely novel. This image is embedded as the authenticity marker. A corresponding GAN discriminator model, or a perceptual hash comparison, can be used by a trusted client to verify that the marker is a legitimate output of the authentic generator and not a crude imitation.

Mermaid Diagram:

graph TD
    subgraph Server
        A[Request Received] --> B(Generate Seed);
        B --> C(Create Latent Space Vector);
        C --> D[GAN Generator Model];
        D --> E(Generate AI Image Marker);
    end
    subgraph Client
        F[Data with Marker Received] --> G{Verify Marker};
        G --> H{Perceptual Hash or Discriminator Check};
        H --> I[Display Authenticated Content];
    end
    E --> F;

4.2. Blockchain-Anchored Fractal Generation

Enabling Description: To provide decentralized and publicly verifiable authenticity, this system combines fractal generation with a blockchain. The authentication server generates a fractal marker as usual. It then computes a hash of the electronic content (e.g., a web page) it is authenticating. The server records a transaction on a public ledger (e.g., an Ethereum smart contract) containing the content hash and the seed used to generate the fractal. The client receives the content with the embedded fractal. For verification, the client's browser plugin re-computes the hash of the received content, queries the blockchain for that hash, and retrieves the associated fractal seed. It then locally regenerates the fractal using the retrieved seed and compares it to the fractal embedded in the content. A match provides immutable, third-party-verifiable proof of the content's authenticity at a specific point in time.

Mermaid Diagram:

sequenceDiagram
    participant Client
    participant Server
    participant Blockchain

    Client->>Server: Request data
    Server->>Server: Retrieve data, compute contentHash
    Server->>Server: Generate fractalSeed, generate fractalImage
    Server->>Blockchain: Record transaction (contentHash, fractalSeed)
    Server->>Client: Return data + fractalImage
    Client->>Client: Re-compute contentHash from received data
    Client->>Blockchain: Query for contentHash
    Blockchain-->>Client: Return stored fractalSeed
    Client->>Client: Locally re-generate fractal from fractalSeed
    Client->>Client: Compare received fractal with re-generated fractal

5. "Inverse" or Failure Mode

5.1. Graceful Degradation Marker System

Enabling Description: This system is designed to maintain a level of authentication service under high server load or in low-power modes. The authentication server monitors its own performance metrics (CPU load, memory usage). It defines several operational tiers.
- Tier 1 (Normal Load): Full, high-iteration fractal generation.
- Tier 2 (Medium Load): Switches to a lower-iteration fractal or a pre-computed pattern from a secure, rotating cache.
- Tier 3 (High Load): Generates a simple visual hash (e.g., a "hashlet") by mapping bytes of a session key hash to a grid of colored squares.
  The generated marker includes metadata indicating its tier. The client UI visually distinguishes between the tiers (e.g., a gold border for Tier 1, silver for Tier 2, bronze for Tier 3), informing the user of the current, temporarily reduced security level without failing the entire process.

Mermaid Diagram:

stateDiagram-v2
    state "Tier 1: Full Security" as T1
    state "Tier 2: Medium Security" as T2
    state "Tier 3: Low Security" as T3

    [*] --> T1: Normal Load
    T1 --> T2: CPU Load > 70%
    T2 --> T1: CPU Load < 50%
    T2 --> T3: CPU Load > 90%
    T3 --> T2: CPU Load < 80%

    T1: Generate High-Iteration Fractal
    T2: Generate Low-Iteration Fractal
    T3: Generate Visual Hashlet

Combination with Open-Source Standards

1. Combination with OpenID Connect (OIDC)

Enabling Description: To combat phishing attacks against identity providers, the OIDC authentication flow is enhanced with a visual marker. When a user is redirected to the Authorization Server's login page, the server generates a fractal marker. The seed for this fractal is derived from a hash of the client_id (representing the application the user is logging into) and the nonce parameter from the authentication request. This fractal is displayed prominently on the login page. The user, having seen this pattern before during initial setup, can visually confirm they are on the legitimate OIDC provider's site and are authorizing the correct application before entering their credentials.

2. Combination with Scalable Vector Graphics (SVG) Standard

Enabling Description: The authenticity marker is generated as an SVG XML document instead of a raster image. The fractal-generating algorithm's core parameters (e.g., algorithm type, seed, iteration count, color palette) are embedded directly into the SVG file as custom <metadata> tags or within <desc> elements. This has two benefits: 1) The marker is resolution-independent and lightweight. 2) A client-side script can parse the SVG's XML structure, extract the generation parameters, and cryptographically verify them against a public key or a server-provided signature without needing complex image processing or OCR, thus confirming the marker's authenticity.

3. Combination with JSON Web Tokens (JWT)

Enabling Description: A system for visually authenticating physical or digital access passes that use JWTs. A server issues a JWT to a client (e.g., a mobile app) for a time-limited session. In addition to the standard JWT, the server generates a fractal marker whose seed is a hash of the JWT's payload (including the jti and exp claims) and a server secret. The mobile app displays this fractal alongside a QR code containing the JWT. When a validator scans the QR code, it verifies the JWT's signature and then independently re-generates the fractal using the JWT payload and a shared secret. The validator's screen displays the re-generated fractal, which the security personnel must visually match to the one on the user's mobile device, providing a powerful two-factor (digital signature + visual) authentication of the token.