Derivative works

Defensive Disclosure and Prior Art Generation

Publication Date: May 12, 2026
Reference Patent: U.S. Patent 6,546,397 ("the '397 patent")
Field: Web Development, Software Engineering, Human-Computer Interaction
Disclosed by: Senior Patent Strategist and Research Engineer

This document serves as a defensive publication of derivative works and improvements related to the art described in U.S. Patent 6,546,397. The purpose of this disclosure is to place these concepts into the public domain, thereby establishing them as prior art to render obvious or anticipate future patent claims in this technological area.

---

Derivatives of Core Claim 1: A Browser-Based Web Page Build Tool

The core concept of the '397 patent involves a method for building a web page within a browser using a WYSIWYG interface, where a build engine generates a single run-time file and an associated database for client-side rendering. The following derivatives expand upon this foundation.

Axis 1: Architectural & Component Substitution

This axis explores alternative software architectures, data formats, and component technologies that achieve the same functional outcome as the '397 patent.

Derivative 1.1: WebAssembly (WASM) Based Build & Run-Time Engine

• Enabling Description: The build engine and run-time engine, described in the '397 patent as potentially being Java-based, are instead compiled to a single WebAssembly (.wasm) binary. The build tool's user interface, written in HTML/JavaScript, communicates with the WASM build engine via the JavaScript WASM API. This allows for near-native performance for complex operations like image manipulation, 3D rendering, and physics simulations directly within the browser. The run-time package consists of the .wasm engine, a JSON or msgpack database, and a lightweight HTML/JS loader. The .wasm run-time engine is responsible for reading the database and rendering the page content directly to an HTML5 Canvas element or by manipulating the DOM.
• Mermaid Diagram:

  graph TD
      A[User Interaction in Browser UI] --> B{HTML/JS Interface};
      B --> C[JavaScript WASM API];
      C <--> D[WASM Build Engine];
      D --> E[Generate JSON/msgpack Database];
      D --> F[Generate WASM Run-Time Engine];
      subgraph Client Browser (End User)
          G[HTML/JS Loader] --> H[WASM Run-Time Engine];
          H --> I[Reads JSON/msgpack Database];
          I --> J[Renders to HTML5 Canvas/DOM];
      end
  

Derivative 1.2: Serverless Function (FaaS) Architecture for Build Process

• Enabling Description: The build engine logic is not a monolithic application but is decomposed into a set of serverless functions (e.g., AWS Lambda, Google Cloud Functions) hosted on a Function-as-a-Service (FaaS) platform. The browser-based UI acts as a thin client, making API calls to these functions for specific tasks (e.g., processImage, generateCSS, compileTimeline). The state of the web page is stored in a cloud-native database like DynamoDB or Firestore. The "run time generation" step triggers a final serverless function that compiles the data from the database into a static site package (HTML, CSS, JS, and data JSON files) and deploys it to a Content Delivery Network (CDN). This architecture eliminates the need for a persistent server and scales dynamically.
• Mermaid Diagram:

  sequenceDiagram
      participant BrowserUI as Browser UI (Thin Client)
      participant APIGateway as API Gateway
      participant FaaS as Serverless Functions (Build Engine)
      participant CloudDB as Cloud Database
      participant CDN as Content Delivery Network
  
      BrowserUI->>APIGateway: User Action (e.g., add image)
      APIGateway->>FaaS: Invoke processImage()
      FaaS->>CloudDB: Store image metadata
      CloudDB-->>FaaS: Confirmation
      FaaS-->>APIGateway: Success
      APIGateway-->>BrowserUI: Update UI
  
      BrowserUI->>APIGateway: PUBLISH_SITE event
      APIGateway->>FaaS: Invoke generateRuntime()
      FaaS->>CloudDB: Read all page data
      CloudDB-->>FaaS: Return data
      FaaS->>CDN: Generate & Deploy Static Files (HTML, JS, JSON)
      CDN-->>FaaS: Deployment Complete
  

Derivative 1.3: Progressive Web App (PWA) as the Build Tool

• Enabling Description: The entire build tool is architected as a Progressive Web App (PWA). A service worker is employed to cache the application shell, assets, and even project data, allowing the entire web site generation tool to function offline. Project data is stored locally using IndexedDB. When the user comes online, the PWA can sync the project data with a central cloud repository. The run-time file generated is also packaged as a PWA, enabling the created websites themselves to be installable and work offline.
• Mermaid Diagram:

  graph TD
      subgraph PWA Build Tool
          A[Browser UI] <--> B[Service Worker];
          B <--> C[Cache Storage API];
          A <--> D[IndexedDB for Project Data];
          B --> E{Network Request};
          E -- Online --> F[Cloud Sync];
          E -- Offline --> G[Serve from Cache];
      end
      A --> H[Generate PWA Run-time];
      H --> I{Service Worker, Manifest.json, IndexedDB};
  

Derivative 1.4: Using GraphQL for Data Definition and Retrieval

• Enabling Description: Instead of a custom multi-dimensional array database, the build tool defines the web page structure using a GraphQL schema. All components, styles, and content are represented as types within this schema. The WYSIWYG interface is a GraphQL client that sends mutations to a GraphQL server (which can be local in the browser via a library like graphql-js or a remote endpoint) to modify the web page. The "run-time file" is a standardized GraphQL client, and the "database" is the GraphQL endpoint's data, which can be delivered as a single JSON blob upon initial load for static sites. This provides strong typing and efficient data fetching for the run-time engine.
• Mermaid Diagram:

  graph LR
      subgraph Build-Time
          UI[WYSIWYG Editor] -- GQL Mutation --> Server{GraphQL Server};
          Server -- Updates --> DB[(Database)];
      end
      subgraph Run-Time
          Loader[JS Loader] -- GQL Query --> Server;
          Server -- JSON Response --> Engine[Run-Time Engine];
          Engine --> Page[DOM Render];
      end
  

Axis 2: Operational Parameter Expansion

This axis defines the technology operating at different scales and under extreme conditions.

Derivative 2.1: Micro-Frontend Run-Time Architecture for Enterprise Scale

• Enabling Description: For websites with thousands of pages managed by different teams, the "single run-time file" concept is expanded into a micro-frontend architecture. The build tool generates independent, self-contained run-time modules for different sections of the website (e.g., product pages, marketing blogs, user dashboards). A container application or "shell" is responsible for loading these micro-frontends on demand. The "database" is federated, with each micro-frontend responsible for fetching its own data. This allows for independent development, deployment, and scaling of different parts of a large web property, all originating from a unified build tool.
• Mermaid Diagram:

  graph TD
      subgraph Unified Build Tool
          TeamA[Team A] --> BuildA[Build Module A];
          TeamB[Team B] --> BuildB[Build Module B];
      end
      BuildA --> RTA[Run-Time Micro-Frontend A];
      BuildB --> RTB[Run-Time Micro-Frontend B];
  
      subgraph User Browser
          Shell[Container App Shell] --> RouteA{URL Route A};
          Shell --> RouteB{URL Route B};
          RouteA --> |Load| RTA;
          RouteB --> |Load| RTB;
      end
  

Derivative 2.2: Low-Bandwidth/Intermittent Connectivity Mode

• Enabling Description: The build tool includes a "low-bandwidth" profile. When this profile is selected, the run-time generation process aggressively optimizes for minimal data transfer. Images are converted to modern, low-size formats like AVIF/WebP with heavy compression, and CSS/JS are minified and pruned of non-essential features. The run-time engine first loads a textual or low-fidelity version of the page, then progressively enhances the page with richer content (images, animations) only as bandwidth becomes available, using techniques like the Network Information API to monitor connectivity. The database is structured to prioritize the loading of above-the-fold content first.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Loading
      Loading --> LowFidelity: Poor Connection
      Loading --> FullExperience: Good Connection
      LowFidelity --> FullExperience: Connection Improves
      FullExperience --> LowFidelity: Connection Degrades
      state Loading {
          direction LR
          [*] --> CheckBandwidth
          CheckBandwidth --> RenderText
      }
      state LowFidelity {
          direction LR
          [*] --> LoadPlaceholders
          LoadPlaceholders --> MonitorNetwork
      }
      state FullExperience {
          direction LR
          [*] --> LoadRichMedia
      }
  

Axis 3: Cross-Domain Application

This axis describes applications of the core mechanism in unrelated industries.

Derivative 3.1: Aerospace - Interactive Cockpit Display Configuration

• Enabling Description: A ruggedized, tablet-based tool runs a browser-based build engine for configuring avionics displays in a glass cockpit. Pilots or maintenance crew use a WYSIWYG interface to drag-and-drop gauges, warning indicators, and data readouts (e.g., engine temp, altitude, fuel flow) onto a virtual cockpit panel. The "build engine" validates the layout against safety and certification standards (e.g., DO-178C). The "run-time file" and "database" are a single, cryptographically signed configuration file loaded by the aircraft's primary flight display system, which then renders the custom interface.
• Mermaid Diagram:

  flowchart LR
      subgraph Ground Tablet
          A[UI: Drag & Drop Gauges] --> B[Build Engine];
          B -- Validate --> C{DO-178C Rules Engine};
          B --> D[Generate Signed Config File];
      end
      subgraph Aircraft Cockpit
          E[Flight Display System] -- Loads --> D;
          E --> F[Render Custom Cockpit UI];
      end
  

Derivative 3.2: AgTech - Dynamic Irrigation & Sensor Dashboard Builder

• Enabling Description: Farmers and agronomists use a web-based tool to design custom dashboards for managing their fields. They can drag representations of sensor data (soil moisture, pH, temperature) and controls (irrigation pivots, drone deployment waypoints) onto a satellite map of their farm. The build engine generates a run-time file that is executed on tablets or in-vehicle displays. This run-time engine connects via an IoT protocol (e.g., MQTT) to the farm's sensors and actuators, providing a live, custom-built control interface for precision agriculture.
• Mermaid Diagram:

  sequenceDiagram
      participant Farmer as Farmer @ Web UI
      participant BuildEngine as Build Engine
      participant DashboardRT as Field Dashboard Run-Time
      participant IoTPlatform as Farm IoT Platform
  
      Farmer->>BuildEngine: Designs dashboard (maps, sensors, controls)
      BuildEngine->>Farmer: Generates Run-Time & Database
      DashboardRT->>IoTPlatform: Connect and Subscribe to MQTT topics
      IoTPlatform-->>DashboardRT: Live Sensor Data (moisture, pH)
      DashboardRT-->>Farmer: Display Live Data
      Farmer->>DashboardRT: Activate Irrigation
      DashboardRT->>IoTPlatform: Publish 'irrigation: on' message
  

Derivative 3.3: Consumer Electronics - Smart Home "Scene" Creator

• Enabling Description: A smart home app features a browser-based interface for creating "scenes" (e.g., "Movie Night," "Good Morning"). Users visually arrange icons for lights, smart shades, thermostats, and speakers, setting their desired states (e.g., dim lights to 20%, close shades, set temp to 70°F). The build engine compiles these user choices into a compact JSON "database" and a small JavaScript "run-time" function. When the user activates the scene, the home hub executes this specific run-time function, which iterates through the JSON and sends the corresponding commands to the various smart devices via the local network.
• Mermaid Diagram:

  graph TD
      A[User designs 'Movie Night' scene] --> B{Build Engine in App};
      B --> C[Generate Scene.js run-time];
      B --> D[Generate Scene.json database];
      E[User taps 'Movie Night'] --> F[Smart Home Hub];
      F -- Executes --> C;
      C -- Reads --> D;
      C --> G[API Call: Set Lights to 20%];
      C --> H[API Call: Close Shades];
  

Axis 4: Integration with Emerging Tech

This axis describes integration with AI, IoT, and Blockchain.

Derivative 4.1: AI-Driven A/B Testing & Layout Optimization

• Enabling Description: The build tool integrates a machine learning model. As a user designs a web page, the AI provides real-time suggestions to improve user engagement, such as re-arranging buttons, changing color schemes, or suggesting alternative headlines. Upon publishing, the run-time generation engine doesn't create one database, but multiple variations (e.g., db_A.json, db_B.json). The run-time engine includes logic to serve different versions to different users and track conversion metrics (e.g., clicks, sign-ups). This data is fed back to the AI model, which automatically optimizes the page layout over time by favoring the best-performing variations.
• Mermaid Diagram:

  flowchart TD
      A[User Designs Page] --> B{Build Engine};
      C[AI Optimization Model] -- Suggestions --> A;
      B --> D[Generate Multiple DB Variations];
      E[Run-Time Engine] --> F{Serve Variation A or B};
      G[User Interaction] --> H[Track Metrics];
      H -- Feedback Loop --> C;
  

Derivative 4.2: IoT-Aware Dynamic Content

• Enabling Description: The build tool allows the user to link page elements to live IoT sensor data streams via a REST or WebSocket API. For example, a background image could be linked to a local weather station's API, changing from sunny to rainy based on real-time conditions. A product availability status could be linked directly to a warehouse inventory sensor. The run-time engine maintains a persistent connection to these data sources and updates the DOM dynamically as new IoT data arrives, without requiring a page reload. The "database" contains the mappings between page element IDs and their corresponding IoT data endpoints.
• Mermaid Diagram:

  classDiagram
    class PageElement {
      +elementId: string
      +iotEndpoint: URL
      +update()
    }
    class RuntimeEngine {
      +iotConnections: Map<string, WebSocket>
      +elementMap: Map<string, PageElement>
      +init()
      +handleMessage(data)
    }
    RuntimeEngine "1" -- "*" PageElement : contains
  

Derivative 4.3: Blockchain-Verified Content & Asset Provenance

• Enabling Description: The build tool integrates with a distributed ledger (blockchain). When a user uploads an image or writes a piece of text, a hash of that asset is created and stored on the blockchain, creating an immutable record of its origin and timestamp. The run-time generation process includes these blockchain transaction hashes in the site's database. The run-time engine can optionally include a feature for end-users to click a "verify" icon next to an asset, which queries the blockchain to prove the authenticity and provenance of the content they are viewing. This is applicable for journalism, legal documents, or digital art.
• Mermaid Diagram:

  sequenceDiagram
      participant User as Web Designer
      participant BuildTool as Build Tool
      participant Blockchain as Distributed Ledger
      participant EndUser as Site Visitor
      participant Runtime as Run-Time Engine
  
      User->>BuildTool: Uploads image.jpg
      BuildTool->>Blockchain: Hashes image and creates transaction
      Blockchain-->>BuildTool: Returns Transaction ID
      BuildTool->>BuildTool: Stores Tx ID in site database
      ...
      EndUser->>Runtime: Clicks 'Verify' on image
      Runtime->>Blockchain: Queries using stored Tx ID
      Blockchain-->>Runtime: Returns original hash & timestamp
      Runtime->>EndUser: Displays verification checkmark
  

Axis 5: The "Inverse" or Failure Mode

This axis describes safe failure modes or limited-functionality versions.

Derivative 5.1: Graceful Degradation to a "No-Script" Static Version

• Enabling Description: The build tool has a "Generate Static Fallback" option. When selected, the run-time generation process creates not only the dynamic run-time file and database but also a pure, static HTML and CSS version of the page. The initial HTML shell includes the static content within <noscript> tags. If a user's browser has JavaScript disabled, it will render the functional, albeit non-interactive, static version. The dynamic run-time engine, if it runs, will clear the static content and render the full interactive experience. This ensures content accessibility under all conditions.
• Mermaid Diagram:

  graph TD
      A[Build Tool] --> B[Generate Dynamic Run-Time];
      A --> C[Generate Static HTML/CSS Fallback];
  
      subgraph User Browser
          D[HTML Shell] -- JS Enabled --> E{Load Run-Time};
          E --> F[Render Dynamic Page];
          D -- JS Disabled --> G{Render content inside <noscript> tag};
          G --> H[Display Static Page];
      end
  

Derivative 5.2: Safe Mode for Content Editing

• Enabling Description: The run-time engine includes a "safe mode" that can be triggered by a special URL parameter (e.g., ?edit-safe=true). In this mode, all complex animations, transformations, and user interaction scripts are disabled. The engine only performs the basic layout and rendering of text and images. This allows content editors with appropriate permissions to log in and make simple text or image changes on a live site without the risk of triggering complex, and potentially buggy, interactive features. It provides a stable, predictable environment for minor content updates.
• Mermaid Diagram:

  stateDiagram-v2
      state "Normal Mode" as Normal
      state "Safe Mode" as Safe
  
      [*] --> Normal: Default Load
      Normal --> Safe: URL param `?edit-safe=true`
      Safe --> Normal: Remove URL param
  
      state Normal {
          description All features enabled
      }
      state Safe {
          description Animations: Disabled
          description Scripts: Disabled
          description Transitions: Disabled
      }
  

---

Combination Prior Art with Open-Source Standards

1. Combination with git and Markdown: A version of the '397 build tool where the browser-based editor is an interface for a git repository. All content is stored as Markdown (.md) files in the repository. The user's actions in the WYSIWYG editor translate into git commits. The "run-time generation" process is a CI/CD pipeline (like GitHub Actions) that is triggered on a git push. This pipeline runs a static site generator (e.g., Jekyll, Hugo) which reads the Markdown files and generates the final HTML, CSS, and JS files. The core concept of a browser-based tool creating a runnable site remains, but the underlying database and generation engine are replaced by ubiquitous open-source standards.

2. Combination with Web Components Standard: The build tool is a Web Components-based editor. Users drag and drop standard or custom HTML elements (e.g., <product-card>, <image-gallery>) into the WYSIWYG view. The "database" is simply a JSON file that describes the tree of selected components and their attributes/properties. The "run-time file" is a minimal JavaScript loader that parses this JSON and dynamically creates the component instances in the DOM. This leverages the browser's native component model, making the run-time extremely lightweight and interoperable.

3. Combination with xterm.js and CLI Tools: The browser-based tool presents a hybrid UI: a visual WYSIWYG editor side-by-side with a web-based terminal powered by xterm.js. Visual edits made by the user in the GUI automatically generate and execute commands for a command-line interface (CLI) tool (like Vite or create-react-app) in the terminal. The "database" is the source code itself (e.g., React JSX files, Vue components), and the "run-time file" is the standard bundled output from these open-source build tools. This approach combines the visual convenience of the '397 patent with the power and ubiquity of modern CLI-driven web development workflows.