US 11379651

US patent 11379651, titled "Methods and systems for interactive content creation," was filed on June 15, 2021, and issued on July 5, 2022. The original assignee was Turtl Surf and Immerse Ltd, which also remains the current assignee following a corrective assignment on October 28, 2024. Nicholas Kingsley Mason is the inventor.

Abstract:
The patent describes a system for personalizing interactive content. This system includes a content creation component that creates modular content items for a document, with at least one item having rules defining links to other documents or assembly instructions for a personalized document. A content personalization component receives personalization instructions, assembles multiple modular content items from various documents based on these rules, and then renders the resulting personalized document using a specified brand style.

Plain-language overview of independent claims:

The provided patent text does not explicitly list numbered claims, but the "Summary" section outlines two primary aspects which typically correspond to the independent claims:

1. System for Automatically Assembling an Interactive Document: This system comprises a server connected to user devices over a network. The server is configured to embed a first set of rules into a modular item of a first document. It then receives parameters for personalizing the first document, and based on these parameters and the embedded rules, pulls a second modular item from a second document. Finally, it assembles this second modular item with the first document to create a new, personalized "derivative document".
2. System for Personalizing an Interactive Document: This system includes two main components. A first component creates modular content items for a document, where at least one item contains rules that define a link to another document or dictate how it should be assembled into a derivative document. A second component receives instructions for personalizing a specific document. It then assembles various modular items from the given document and other documents, guided by the rules associated with the modular items of the given document, to generate a derivative document. This derivative document is then rendered using a style associated with the original document.

Litigation Status:
As of April 26, 2026, the patent US11379651B1 is listed as "Active". The Google Patents record indicates that "Family has litigation" and that "First worldwide family litigation filed". A link to Darts-ip is provided for more details on this litigation. Searching the CAFC 2026 dockets for patent number 11379651 did not return any direct results as of April 26, 2026. This suggests that while there may be litigation involving the patent family, it might not be a direct appeal case in the CAFC for 2026, or the public docket information is not yet available through standard searches. Further investigation into the Darts-ip record would be necessary for specific litigation details.

tool_code
print(google_search.search(queries=["US11379651 litigation", "Turtl Surf and Immerse Ltd patent litigation", "11379651 CAFC docket 2026", "11379651 PACER litigation"]))
thought
The user is asking for known litigation involving US patent 11379651. I need to search for this specific patent number on patent litigation sites and provide details for each case found, including plaintiff(s), defendant(s), jurisdiction, case number, filing date, and outcome or current status. If no litigation is found, I should state that. I have been instructed to use the provided Google Patents link and Darts-ip link as a starting point, and also to search CAFC and PACER. My previous search for CAFC 2026 dockets did not return direct results. I will broaden my search to generally look for litigation involving US11379651.Based on the available search results, no specific litigation cases directly involving US patent 11379651 have been identified. While the Google Patents record for US11379651 indicates that "Family has litigation" and "First worldwide family litigation filed," the conducted searches of general patent litigation databases and legal news sources did not return details for any cases listing US11379651 as the patent in suit. Further investigation into the Darts-ip record mentioned in the patent's Google Patents entry would be necessary for specific litigation details.

Proceedings overview

There is one active AIA trial proceeding on file for US patent 11379651. This Inter Partes Review (IPR) is currently in the preliminary stages, with the petition recently filed and the institution decision pending. This means the patent's claims are currently challenged but no final determination on validity has been made by the PTAB.

IPR2026-00404 — Foleon Inc. et al. v. Nicholas Kingsley Mason

• Type: Inter Partes Review
• Filed: 2026-07-16
• Status: Pending. The petition was recently filed, and the PTAB has not yet made a decision on whether to institute the IPR.
• Judge panel: The judge panel has not yet been made public at this early stage of the proceeding.
• Petition grounds: Details regarding the specific claims challenged, prior art references, and statutory bases (§ 102 / § 103 / § 112) of the petition are not publicly available from the provided information due to the very recent filing date.
• Institution decision: Not yet issued. The PTAB has approximately six months from the filing date to issue a decision on institution.
• Final Written Decision (if issued): Not applicable, as the IPR has not yet been instituted.
• Settlement / termination: Not applicable at this stage.
• Appeal: Not applicable at this stage.
• Defensive value: This proceeding indicates that Foleon Inc. et al. believe there are grounds to challenge the patent's validity. For a defendant, this means the patent is currently under PTAB scrutiny, and there is a possibility that claims could be invalidated. However, until an institution decision is made and, if instituted, a Final Written Decision is issued, all claims remain presumptively valid.

Strategic summary

As of the current date, all claims of US patent 11379651 are currently UNTESTED by a final PTAB decision. The patent is the subject of a newly filed Inter Partes Review, IPR2026-00404, by Foleon Inc. et al. Since the petition was just filed on 2026-07-16, the PTAB has not yet determined whether to institute the trial. Therefore, no claims have been canceled or definitively sustained by the PTAB.

Regarding estoppel, if IPR2026-00404 is instituted and proceeds to a Final Written Decision, Foleon Inc. et al. (and any parties in privity with them) would be estopped under 35 U.S.C. § 315(e)(2) from asserting in future litigation that a claim is invalid on any ground that the petitioner raised or reasonably could have raised during the IPR. Until then, the full range of prior art grounds remains available to other potential defendants. It is too early to discern any patterns regarding multiple IPR filings on this patent or aggressive PTAB appeal strategies by the patent owner, as this is the first and only PTAB proceeding recorded.

Recommended next steps

For a defendant facing assertion of US patent 11379651, the primary recommended next step is to closely monitor IPR2026-00404. The most critical upcoming milestone is the institution decision, which is expected around 2027-01-16 (six months from the petition filing date). A decision to institute would signal that the PTAB believes there is a reasonable likelihood that at least one claim is unpatentable, increasing the potential for claims to be invalidated. If the IPR is instituted, reviewing the institution decision will provide insight into the specific claims and prior art grounds the PTAB has accepted for trial.

Inventors

Nicholas Kingsley Mason is the sole named inventor. The patent does not explicitly state his employer at the time of filing.

Original assignee

The original assignee is Turtl Surf and Immerse Ltd. Based on the patent's description, which focuses on "methods and systems for interactive content creation" and mentions "digital magazines, case studies, product guides, sales playbooks," it appears Turtl Surf and Immerse Ltd is an operating company developing software and services in the interactive content space. The current legal status of the patent is "Active," and Turtl Surf and Immerse Ltd remains the current assignee, indicating it is likely still an operating entity.

Assignment timeline

• 2021-07-30 (executed) / recorded 2021-07-30 — Reel 057462/0058

  • Conveyance: Assignment of Assignors Interest
  • Assignor: MASON, NICHOLAS KINGSLEY
  • Assignee: Turtl Surf & Immerse Limited
  • Correspondent: BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023
  • Context: Transfer from inventor to original assignee

• 2023-05-26 (executed) / recorded 2023-05-26 — Reel 060515/0501

  • Conveyance: Security Interest
  • Assignor: Turtl Surf & Immerse Limited
  • Assignee: SILICON VALLEY BANK UK LIMITED
  • Correspondent: BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023. This correspondent recurs.
  • Context: Securitization of assets for a loan

• 2024-10-28 (executed) / recorded 2024-10-28 — Reel 063688/0001

  • Conveyance: Corrective Assignment
  • Assignor: MASON, NICHOLAS KINGSLEY
  • Assignee: Turtl Surf & Immerse Limited
  • Correspondent: BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023. This correspondent recurs.
  • Context: Correction of a previous assignment from inventor to original assignee

Timeline diagram

timeline
    title Ownership of US 11379651
    2021 : Filed by Turtl Surf and Immerse Ltd
         : Assigned from Inventor Mason to Turtl Surf & Immerse Ltd
    2022 : Issued
    2023 : Security Interest to Silicon Valley Bank UK
    2024 : Corrective Assignment from Inventor Mason to Turtl Surf & Immerse Ltd

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The patent has remained with Turtl Surf and Immerse Ltd, an operating company. Transfers were from the inventor or for security purposes.
2. Known asserter in the chain — not present. None of the named assignees (Turtl Surf & Immerse Limited, SILICON VALLEY BANK UK LIMITED) are on common public NPE lists.
3. Repeat correspondent across the chain — present. BRENT JOHNSON, P.O. BOX 1071, LOS ALTOS, CA 94023, appears as the correspondent for all three recorded assignments (Reel 057462/0058, Reel 060515/0501, and Reel 063688/0001). This consistency in correspondent for different types of assignments (inventor assignment, security interest, corrective assignment) is a signal.
4. Cascading transfers — not present. There are only three assignments recorded over a period of several years, and they are not consecutive transfers through different LLCs.
5. Pre-litigation transfer — unclear. While the Google Patents record indicates "Family has litigation," no specific lawsuit filing dates naming this patent were found to compare against the assignment dates. Therefore, it's not possible to determine if any assignment preceded litigation within a 6-month window.
6. Bankruptcy fire-sale — not present. There is no indication that Turtl Surf and Immerse Ltd has filed for bankruptcy. The security interest with Silicon Valley Bank UK Limited is a normal business transaction, not necessarily indicative of bankruptcy.
7. Privateering — not present. No evidence from SEC filings or other sources suggests a privateering arrangement.
8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at any known defensive aggregators.

Verdict

Insufficient data. While there is a repeat correspondent, which can sometimes be a signal for NPE activity, the patent currently remains with the original operating assignee, Turtl Surf & Immerse Limited. There are no shell-entity transfers, known NPE assignees, or cascading transfers. The litigation status is unclear from public records regarding this specific patent, making it impossible to assess pre-litigation transfer signals. More information about the "family litigation" would be needed to make a more definitive assessment.

Verification: USPTO Assignment Center search for US11379651

To identify the most relevant prior art for US patent 11379651, I need to access the full patent document, specifically its "References Cited" section. The provided text is the full patent text, so I will analyze it directly.

Understanding Anticipation (35 U.S.C. § 102)

Anticipation under 35 U.S.C. § 102 means that an invention is "not novel" because every element of the claimed invention is found, either expressly or inherently described, in a single prior art reference that was publicly available before the effective filing date of the claimed invention. The elements must be arranged as required by the claim. If a prior art reference discloses a method that, when followed, inevitably produces the claimed invention, it can inherently anticipate the claim.

Analysis of Cited Prior Art for US11379651:

The patent text provided explicitly states:

"This application claims the priority and benefit of U.S. Provisional Application No. 63/048,512 filed on Jul. 6, 2020, the entire contents of which is incorporated herein by reference."

This provisional application is the primary prior art identified by the patent itself. Since it is a provisional application that this patent claims priority from, it generally would not anticipate the claims of this patent under 35 U.S.C. § 102, as long as the claims of US11379651 are fully supported by the provisional application. Instead, it serves as the priority document. Prior art for anticipation would typically come from earlier, distinct disclosures.

The provided patent text does not list any other "References Cited" from the patent examination process (e.g., U.S. Patents, Foreign Patent Documents, or Other Publications). Therefore, based on the provided document, the only explicit "prior art" reference is the provisional application from which it claims priority, which is not used for 35 U.S.C. § 102 anticipation against its own claims.

Conclusion on Most Relevant Prior Art (based solely on the provided patent text):

Based only on the full patent text provided, the patent US11379651 does not explicitly list any prior art references that were cited against its claims during prosecution (e.g., in a "References Cited" section). The only reference mentioned is U.S. Provisional Application No. 63/048,512, filed on July 6, 2020, which is a priority document and not typically used for anticipation under 35 U.S.C. § 102 against the claims of the patent claiming its benefit.

To perform a comprehensive prior art analysis for potential anticipation under 35 U.S.C. § 102, I would need to access the full prosecution history of US11379651, typically found in the USPTO's Patent Center or Patent Public Search tool, to review the Examiner's citations and any prior art submitted by the applicant. This information is not present in the provided patent grant document.

Based on the "Prior Art" section provided, US patent 11379651 does not explicitly list any prior art references that were cited against its claims during prosecution, other than its own priority document (U.S. Provisional Application No. 63/048,512).

An obviousness analysis under 35 U.S.C. § 103 requires identifying a combination of at least two prior art references, or a single reference combined with general knowledge in the art, that would have made the claimed invention obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention. This analysis also requires identifying a motivation to combine those references and a reasonable expectation of success.

Since the provided patent text does not include a "References Cited" section listing distinct prior art documents, and the only other reference is a priority document (which cannot be used for obviousness against its own claims), it is not possible to perform an obviousness analysis under 35 U.S.C. § 103 with the information currently available.

To conduct a proper obviousness analysis, access to the full prosecution history of US11379651 and any prior art cited by the examiner or applicant would be necessary.

tool_code
print(google_search.search(queries=["US11379651 patent term adjustment extension continuation divisional family members expiration date", "USPTO Patent Center US11379651"]))
thought
The user is asking for specific details about US patent 11379651, including PTAs, PTEs, continuation/divisional applications, related family members, and the projected expiration date. I need to search the USPTO database (or a reliable patent information source) for this specific patent number and extract this information.

From the previously generated sections, I already know:

• Publication number: US11379651B1
• Application number: US17/347,899
• Filing date: 2021-06-15
• Publication date: 2022-07-05 (Application granted)
• Anticipated expiration: 2041-06-15 (from Google Patents)
• Priority date: 2020-07-06 (from US Provisional Application No. 63/048,512)

I need to find explicit information about:

• Patent Term Adjustments (PTA)
• Patent Term Extensions (PTE)
• Continuation applications
• Divisional applications
• Related family members (beyond what's already noted in the priority chain from Google Patents, which lists US17/503,675, US17/830,566, US18/357,451, US18/887,157)
• Confirm the projected expiration date.

I will use the USPTO Patent Center for the most authoritative information.## Patent Term Adjustments (PTA)

Patent Term Adjustment (PTA) can increase the term of a U.S. patent to compensate for certain delays by the U.S. Patent and Trademark Office (USPTO) during prosecution. The standard patent term is 20 years from the filing date of the earliest-filed non-provisional application in the family.

For US patent 11379651, no specific Patent Term Adjustment (PTA) has been identified in the provided patent text or search results. To definitively determine if any PTA was granted, it would be necessary to review the official patent grant document or the prosecution history available through USPTO Patent Center for the specific application (US17/347,899).

Generally, PTA is granted if the USPTO fails to:

• Issue a first Office Action or notice of allowance within 14 months of filing.
• Issue a responsive Office Action within four months of an applicant's complete reply.
• Issue the patent within four months of payment of the issue fee.
• Issue a patent within three years of the actual filing date, with certain exclusions for applicant-caused delays.

Any accrued PTA can be reduced for delays caused by the applicant.

Patent Term Extensions (PTE)

Patent Term Extension (PTE) is available under 35 U.S.C. § 156, primarily for patents covering products (such as pharmaceuticals, medical devices, food additives, or color additives) that require regulatory approval from agencies like the Food and Drug Administration (FDA). PTE aims to restore a portion of the patent term lost during this regulatory review process. A PTE can extend a patent's term by up to five years, but not beyond 14 years after FDA approval.

There is no indication in the patent text or search results that US patent 11379651 is eligible for or has received a Patent Term Extension (PTE). The patent's subject matter relates to "Methods and systems for interactive content creation," which typically does not fall under the categories eligible for PTE.

Continuation and Divisional Applications

The provided Google Patents record for US11379651 lists several priority applications, which indicate a family of related applications:

• US17/347,899 (the application leading to US11379651B1)
• US17/503,675 (priority to US11361144B2)
• US17/830,566 (priority to US11755816B1)
• US18/357,451 (priority to US12118290B2)
• US18/887,157 (priority to US20250225309A1)

These entries suggest that US11379651 is part of a larger patent family, with subsequent applications claiming priority back to earlier filings. Without access to the full prosecution history of each, it's not possible to definitively classify each as a continuation, divisional, or continuation-in-part. However, the listed application numbers (e.g., US17/xxx, US18/xxx) and their associated patent/publication numbers suggest a series of related applications stemming from common priority.

Related Family Members

Based on the Google Patents record, the following are related family members, indicated by priority claims:

• US11379651B1 (this patent, application US17/347,899)
• US11361144B2 (related via priority to US17/503,675)
• US11755816B1 (related via priority to US17/830,566)
• US12118290B2 (related via priority to US18/357,451)
• US20250225309A1 (a publication, related via priority to US18/887,157)

These patents and applications share priority with at least one common application, likely the initial provisional application US Provisional Application No. 63/048,512 filed on July 6, 2020.

Projected Expiration Date

The anticipated expiration date for US patent 11379651, as indicated by Google Patents, is 2041-06-15. This date is 20 years from its filing date of June 15, 2021, suggesting no significant Patent Term Adjustment or Extension was applied or publicly recorded. The general term for a U.S. patent is 20 years from its earliest effective filing date.

Defensive Disclosure: US Patent 11379651 Derivative Variations

This document outlines derivative variations of the core claims of US Patent 11379651, aimed at creating defensive prior art to render future incremental improvements obvious or non-novel. The analysis is structured around the two primary independent claims identified in the patent summary, with each claim explored across five distinct axes of innovation.

---

Core Claim 1: System for Automatically Assembling an Interactive Document

Claim Synopsis: A server-based system that embeds rules into a first modular item of a first document, receives personalization parameters, pulls a second modular item from a second document based on these parameters and rules, and then assembles them to generate a derivative document.

---

1. Material & Component Substitution

Derivative 1.1.1: Decentralized Edge-Compute Assembly with Semantic Graph Store

• Enabling Description: The centralized "server" is replaced by a distributed network of edge computing devices (e.g., industrial IoT gateways, local network appliances) that cooperatively handle document assembly. Modular content items, along with their embedded rules, are stored in a distributed semantic graph database (e.g., using Apache Jena with RDF/OWL ontologies) where each node represents a content element and edges represent relationships and assembly rules. Personalization parameters are received via local APIs from user devices or directly from connected sensors. A consensus mechanism (e.g., Raft or Paxos) orchestrates the distributed rule evaluation and modular item fetching across the edge network. Assembly occurs at the edge, reducing latency and bandwidth. The derivative document is a compiled static web asset (e.g., HTML, CSS, JavaScript bundle) served directly from the nearest edge node.

graph TD
    A[User Device] --> B(Local API Gateway)
    B --> C{Edge Compute Cluster}
    C -- Rule Evaluation --> D[Distributed Semantic Graph Store (RDF/OWL)]
    D -- Content Retrieval --> E[Modular Content Repository]
    E --> C
    C -- Assembly --> F{Static Content Compiler}
    F --> G[Derivative Document (Web Asset)]
    G --> A

Derivative 1.1.2: Quantum-Resistant Blockchain-Secured Content Modules

• Enabling Description: Modular content items are cryptographically secured and timestamped on a permissioned blockchain (e.g., Hyperledger Fabric), ensuring immutability and verifiable provenance. Each modular item is associated with a smart contract that encapsulates its assembly rules. The "server" functionality is distributed across a blockchain network as peer nodes. Personalization parameters are submitted as transactions to the blockchain, triggering smart contract execution for rule evaluation and selection of modular items. The second modular item is pulled via a secure, authenticated inter-chain communication protocol (e.g., IBC) from a second document also stored on a potentially different blockchain. The assembly process is a series of verifiable transactions on the ledger, culminating in a hash of the derivative document being committed, while the actual document is assembled off-chain and accessed via a signed URI. Quantum-resistant cryptography (e.g., lattice-based schemes) is used for all cryptographic operations.

sequenceDiagram
    participant U as User Device
    participant PC as Personalization Component
    participant BC as Blockchain Network
    participant SC as Smart Contracts (Rules)
    participant MR as Modular Content Repository
    U->>PC: Submit Personalization Params (Transaction)
    PC->>BC: Record Params, Invoke Smart Contracts
    BC->>SC: Execute Assembly Rules
    SC->>MR: Request Modular Items (via secure API)
    MR-->>SC: Deliver Item Hashes/IDs
    SC-->>BC: Propose Assembled Document Hash
    BC-->>PC: Confirm Assembly Transaction
    PC->>MR: Assemble Off-chain Document
    MR-->>U: Serve Signed Derivative Document

Derivative 1.1.3: Ferroelectric RAM (FeRAM) Based Server with Event-Driven Processors

• Enabling Description: The server employs specialized processing units featuring Event-Driven Processors (EDPs) optimized for asynchronous task execution and low-power operation. All memory components, including for storing software instructions and structured data of modular items, are implemented using Ferroelectric RAM (FeRAM). FeRAM provides non-volatile, high-speed, and low-power data storage, enabling instant-on capabilities and persistent rule states even without power. Rule embedding and parameter processing are highly parallelized across EDPs. The "pulling" mechanism leverages direct memory access (DMA) between FeRAM modules containing documents and modular items, accelerating data retrieval without CPU overhead. The entire system is designed for extreme energy efficiency and resilience against power interruptions, crucial for mission-critical content delivery in remote or unstable environments.

graph LR
    A[User Request] --> B(Network Interface)
    B --> C(Event-Driven Processor Cluster)
    C -- Reads Rules/Content --> D[FeRAM Document Store]
    D -- Structured Data --> E[FeRAM Rule Store]
    C -- Evaluates --> E
    E --> F{Assembly Logic (EDP)}
    F -- Pulls Content --> D
    F -- Generates --> G(Derivative Document)
    G --> B

---

2. Operational Parameter Expansion

Derivative 1.2.1: Exascale Multi-Modal Document Assembly for Real-time Immersive Experiences

• Enabling Description: This system operates on a compute cluster capable of exascale processing, assembling hyper-personalized interactive content for millions of concurrent users within a single-digit millisecond latency for immersive virtual or augmented reality environments. The "modular items" are not merely text or images, but volumetric video segments, haptic feedback profiles, spatial audio cues, and dynamic environmental shaders. "Documents" are entire virtual worlds or complex simulated environments. Rules are evaluated against thousands of real-time biometric and environmental parameters (e.g., pupil dilation, skin conductance, gaze tracking, ambient light, user posture). The system leverages GPU-accelerated ray tracing and real-time physics engines for on-the-fly rendering and assembly of these multi-modal components into a seamless, responsive derivative experience.

graph TD
    A[Millions of User Sessions (VR/AR)] --> B(Real-time Biometric/Env. Data Ingest)
    B --> C{Exascale Compute Cluster (GPUs)}
    C -- Rule Eval (1000s of params) --> D[Massive Multi-modal Content Repository]
    D -- Volumetric Video, Haptics, Audio, Shaders --> C
    C -- Real-time Assembly & Rendering --> E[Personalized Immersive Experience]
    E --> A

Derivative 1.2.2: Hyperspectral Content Personalization for Specialized Scientific Data

• Enabling Description: The system is designed to handle "documents" comprising hyperspectral data cubes (e.g., from satellite imagery, medical imaging, material science sensors), where "modular items" are specific spectral bands, spatial regions, or temporal slices. Personalization parameters include specific wavelengths of interest, geological features, tissue types, or chemical compositions. The "first set of rules" embeds complex spectral unmixing algorithms and feature extraction criteria within the modular hyperspectral data. The system pulls relevant spectral signatures and spatial components from large-scale hyperspectral archives (second documents), processing data at terabyte-per-second rates. The derivative document is a personalized, fused hyperspectral image product or a multi-dimensional data visualization tailored for specific scientific analysis (e.g., mineral mapping, disease detection, environmental monitoring), rendered with dynamic pseudocoloring and volumetric visualization techniques.

graph TD
    A[Scientist Input (Wavelengths, Features)] --> B(Personalization Parameter Interface)
    B --> C{High-Performance Computing Cluster (Specialized Processors)}
    C -- Rule-Based Spectral Query --> D[Hyperspectral Data Archive (TB/s)]
    D -- Data Cubes, Spectral Libraries --> C
    C -- Processing & Fusion --> E[Personalized Hyperspectral Product]
    E --> F(Multi-Dimensional Visualization)
    F --> A

Derivative 1.2.3: Ultra-Low Latency Financial Report Generation with Predictive Rules

• Enabling Description: This system processes real-time financial market data streams to generate personalized investment reports or risk assessments within sub-millisecond latency. "Modular items" are individual stock charts, economic indicators, news sentiment analyses, or regulatory compliance paragraphs. "Documents" are comprehensive market overviews. The "first set of rules" incorporates predictive analytics models (e.g., ARIMA, LSTM) that, based on real-time market parameters (e.g., volatility, trading volume, sentiment), dynamically trigger the inclusion of forward-looking statements, risk warnings, or bullish/bearish analyses from other documents. The system uses in-memory databases (e.g., Apache Ignite, Redis) for modular item storage and ultra-low latency messaging queues (e.g., Kafka) for parameter ingestion. The derivative document is a dynamic, live-updating financial dashboard or executive summary, continuously adapting to market movements, designed for high-frequency trading decision support.

graph LR
    A[Real-time Market Data Stream] --> B(Ingestion & Parameterization)
    B --> C{Assembly Server (In-Memory DB)}
    C -- Predictive Rules Engine --> D[Modular Financial Content (Charts, News, Analysis)]
    D --> C
    C -- Ultra-low Latency Assembly --> E(Live Personalized Financial Report)
    E --> F[Trading Desks/Analysts]

---

3. Cross-Domain Application

Derivative 1.3.1: Aerospace - Dynamic Aircraft Maintenance Manual Generation

• Enabling Description: The system generates real-time, personalized aircraft maintenance manuals or repair procedures based on current aircraft health monitoring data (from embedded IoT sensors), flight hours, environmental conditions, and technician certifications. "Modular items" are specific repair steps, diagnostic flowcharts, tool lists, safety warnings, or exploded-view schematics (e.g., CAD models). "Documents" are master aircraft service manuals. The "first set of rules" embedded in a task modular item dictates which specific tool variant is required (based on tool crib inventory status), what safety precautions are mandatory (based on current weather conditions or fuel tank levels), or which replacement part version is compatible (based on aircraft serial number and parts inventory). Personalization parameters include tail number, fault code, maintenance station location, and technician skill level. The derivative document is an interactive digital manual displayed on a ruggedized tablet, dynamically updating as new diagnostic data arrives or as the technician progresses through a guided workflow, with direct links to augmented reality overlays for complex procedures.

graph TD
    A[Aircraft Health Monitoring System (IoT Sensors)] --> B(Real-time Aircraft Parameters)
    C[Maintenance Technician Input (Fault Code, Skill)] --> B
    B --> D{Maintenance Manual Assembly Engine}
    D -- Rule Evaluation (Tail No., Fault, Env., Skill) --> E[Modular Maintenance Content (Steps, Tools, Schematics)]
    E -- CAD Models, Safety Warnings, Tool Lists --> D
    D --> F[Interactive Digital Manual (Rugged Tablet)]
    F -- AR Overlays --> F

Derivative 1.3.2: AgTech - Adaptive Crop Management Plan Generator

• Enabling Description: This system automatically generates adaptive crop management plans (e.g., irrigation schedules, fertilization recommendations, pest control strategies) tailored to specific farm plots. "Modular items" represent individual recommendations for nutrient application, watering duration, pesticide types, or harvesting techniques. "Documents" are comprehensive agricultural best practices guides or regional crop advisories. Rules are embedded in each modular recommendation, considering parameters such as real-time soil moisture, nutrient levels (from soil sensors), weather forecasts, satellite imagery-derived plant health indices (NDVI), historical yield data, specific crop variety, and prevailing market prices. Personalization parameters include farm ID, crop type, growth stage, and current nutrient deficiencies. The derivative document is a dynamic, interactive digital farm plan delivered to a farmer's device, with actionable tasks and alerts, capable of integrating with automated farm machinery (e.g., smart irrigation systems, precision sprayers).

graph TD
    A[Environmental Sensors (Soil, Weather)] --> B(Real-time Farm Parameters)
    C[Satellite Imagery (NDVI)] --> B
    D[Historical Yield Data] --> B
    E[Market Prices] --> B
    B --> F{Crop Plan Assembly Engine}
    F -- Rule Evaluation (Plot, Crop, Stage, Deficiencies) --> G[Modular Ag. Recommendations (Irrigation, Fertilizer, Pest)]
    G --> F
    F --> H[Adaptive Digital Farm Plan (Farmer's Device)]
    H -- Integrates with --> I[Automated Farm Machinery]

Derivative 1.3.3: Consumer Electronics - Dynamic Smart Home Device User Guides

• Enabling Description: This system dynamically generates personalized user guides and troubleshooting instructions for complex smart home ecosystems. "Modular items" are setup procedures for specific devices (e.g., smart thermostat, lighting, security camera), integration steps for different brands, or troubleshooting flows for common issues. "Documents" are master manuals for smart home hubs or platforms. The "first set of rules" embedded in a device setup modular item checks for the presence of compatible network protocols (e.g., Zigbee, Z-Wave, Wi-Fi), currently installed smart devices, and user-specified preferences (e.g., accessibility settings, language). Personalization parameters include the user's installed device inventory (detected via API), network configuration, and reported error codes. The derivative document is an interactive, on-demand guide presented through a smart display or mobile application, showing only relevant sections for the user's specific setup and dynamically adapting troubleshooting steps based on real-time device diagnostics.

graph TD
    A[Smart Home Hub (API)] --> B(Device Inventory & Diagnostics)
    C[User Preferences (Accessibility, Language)] --> B
    B --> D{User Guide Assembly Engine}
    D -- Rule Evaluation (Installed Devices, Network, Errors) --> E[Modular User Guide Content (Setup, Integration, Troubleshoot)]
    E --> D
    D --> F[Interactive Smart Display/Mobile App]
    F -- Real-time Diagnostics --> B

---

4. Integration with Emerging Tech

Derivative 1.4.1: AI-Driven Contextual Content Optimization with Real-time IoT Data

• Enabling Description: The system integrates AI-driven optimization directly into the rule generation and document assembly process, augmented by real-time data from IoT sensors. "Modular items" can be content snippets, visual elements, or interactive components. "Documents" are marketing collateral or educational materials. The "first set of rules" is initially defined by authors but is continuously optimized by a Reinforcement Learning (RL) agent. The RL agent observes reader interaction data (dwell time, clicks, scroll depth, conversion rates) and contextual data from IoT sensors (e.g., ambient lighting, noise level, device type, user's physical location, even biometric data like heart rate from wearables, if consented). The RL agent dynamically modifies assembly rules to maximize engagement or conversion goals. Personalization parameters now include real-time environmental context and inferred user emotional state. The derivative document is assembled on the fly, with AI selecting the optimal modular items and presentation styles (e.g., color scheme, font size) for the user's immediate physical and psychological context.

graph TD
    A[Reader Interaction Data] --> B(Analytics & Feedback Loop)
    C[IoT Sensor Data (Ambient, Biometric)] --> D(Contextual Parameters)
    D --> E{Reinforcement Learning (RL) Agent}
    E -- Optimizes/Generates --> F[Dynamic Assembly Rules]
    F --> G{Content Assembly Engine}
    G -- Selects Content --> H[Modular Content Repository]
    H --> G
    G --> I[Personalized Derivative Document]
    I --> J[Reader Device]
    J --> A

Derivative 1.4.2: Blockchain-Verified Supply Chain Document Generation

• Enabling Description: This system generates regulatory compliance documents, product traceability reports, or contractual agreements for complex supply chains, where the authenticity and origin of each "modular item" (ee.g., material certification, manufacturing batch record, shipping manifest, quality assurance report) is verified against immutable records on a public or consortium blockchain (e.g., Ethereum, Corda). The "first set of rules" embedded within a document modular item includes smart contract calls that query the blockchain for specific asset attributes (e.g., "is this component certified organic?", "did this batch pass inspection X?"). Personalization parameters include product ID, manufacturing plant, regulatory jurisdiction, and inspection date range. The assembly engine pulls modular items only after their blockchain-verified status meets the rules. The derivative document, such as a "Digital Product Passport," includes cryptographic hashes of the assembled content, allowing recipients to verify its integrity and the authenticity of its constituent parts against the blockchain.

graph TD
    A[Product ID, Jurisdiction, Date] --> B(Personalization Parameters)
    B --> C{Document Assembly Engine}
    C -- Rule Eval & Smart Contract Query --> D[Blockchain Network (Verified Records)]
    D -- Material Certs, Batch Records, QA Reports --> E[Modular Supply Chain Content]
    E --> C
    C -- Assemble & Hash --> F[Derivative Document (Digital Product Passport)]
    F --> G[Recipient (Verification)]
    G --> D

Derivative 1.4.3: Federated Learning for Privacy-Preserving Rule Optimization

• Enabling Description: Instead of centralized collection of reader interaction data, this system employs Federated Learning to optimize the "assembly rules" for personalized content while preserving user privacy. Each user device maintains a local model of engagement and preference. "Modular items" and their initial "first set of rules" are created centrally. As users interact with derivative documents, their devices locally update their rule optimization models. Periodically, these local model updates (not raw data) are aggregated by a central server (e.g., using secure aggregation techniques) to improve a global rule optimization model. This global model then pushes updated, privacy-preserving rule coefficients or refined rule patterns back to the modular content items. Personalization parameters are processed locally on the user device where possible. The derivative document is assembled with rules enhanced by collective, yet private, user behavior, allowing for improved personalization without direct exposure of individual interaction data.

graph TD
    subgraph Central Server
        A[Global Rule Optimization Model] -- Aggregates Updates --> B(Secure Aggregator)
        B -- Distributes Updates --> C[Modular Content Rule Store]
    end

    subgraph User Device (n)
        D[Local Rule Optimization Model] -- Updates Based On --> E(Reader Interaction)
        E --> F[Personalized Document Display]
        C --> D
        D -- Sends Update --> B
    end

    C -- Initial Rules --> F

---

5. The "Inverse" or Failure Mode

Derivative 1.5.1: Graceful Degradation to Read-Only Static Archive

• Enabling Description: In the event of a catastrophic failure of the personalization or assembly engine (e.g., database outage, rule engine crash, network partition), the system automatically reverts to a "safe failure" mode. The primary objective is to maintain content availability. If real-time personalization parameters cannot be processed or modular items cannot be dynamically pulled, the system accesses a pre-generated, generic, read-only static archive of the "first document." This archive contains the first document in its most basic, unpersonalized form, with all modular items explicitly included in a default order, and all interactive elements disabled. No external modular items are pulled. This "derivative document" is purely informational, stripped of all dynamic capabilities and personalization, ensuring minimal functional disruption and data integrity over advanced features.

stateDiagram
    [*] --> Operational
    Operational --> PersonalizationFailure : Assembly Engine Crash
    Operational --> DatabaseOutage : Content DB Unreachable
    Operational --> NetworkPartition : External Modules Unavailable
    PersonalizationFailure --> SafeMode
    DatabaseOutage --> SafeMode
    NetworkPartition --> SafeMode
    SafeMode --> ServesStaticArchive : Read-Only Document
    ServesStaticArchive --> [*]

Derivative 1.5.2: Low-Power/Limited-Functionality Mode for Resource-Constrained Environments

• Enabling Description: This derivative operates in a "low-power" or "limited-functionality" mode, specifically designed for user devices with severe resource constraints (e.g., low battery, limited CPU, slow network, minimal data plan). The system's "server" side detects these constraints (e.g., via user agent, network latency monitoring, explicit user setting). In this mode, only strictly essential textual "modular items" are assembled, completely omitting high-bandwidth elements like videos, high-resolution images, and complex interactive scripts. All presentation "styles" are simplified to a minimal, monochromatic theme using system-default fonts. The "first set of rules" includes directives for conditional exclusion based on detected device capabilities. Personalization parameters are strictly limited to critical filters (e.g., industry, primary topic), ignoring fine-grained customization. The derivative document is an ultra-lightweight, text-optimized page designed for rapid loading and minimal resource consumption.

graph TD
    A[User Device Request] --> B(Resource Monitor)
    B -- Detects Low-Resource --> C{Low-Power Assembly Engine}
    C -- Filters/Simplifies Rules --> D[Text-Only Modular Content]
    D -- Minimal Styling --> C
    C --> E[Ultra-Lightweight Derivative Document]
    E --> A

Derivative 1.5.3: "Draft Mode" with Rule-Structure-Only Assembly

• Enabling Description: This system provides a "draft mode" primarily for content creators and personalizers to validate the logic of their "first set of rules" and personalization parameter interactions without assembling or rendering the full content. Instead of pulling and assembling actual content, the "second modular item" (and indeed all modular items) are represented by abstract placeholders or metadata cards. The "derivative document" generated in this mode is not a content-rich document, but rather a visual representation of the assembly logic flow. It shows which content types would be included, their sequence, and how they link to various rules and parameters, highlighting any conflicting or unresolved rule conditions. This allows for rapid debugging and validation of complex rule structures before resource-intensive content assembly.

graph TD
    A[Personalizer Input (Parameters)] --> B(Rule Validation Interface)
    B --> C{Draft Mode Assembly Engine}
    C -- Evaluates Rule Logic --> D[Modular Item Metadata/Placeholders]
    D --> C
    C -- Generates --> E[Visual Assembly Logic Flow Diagram]
    E --> B

---

Core Claim 2: System for Personalizing an Interactive Document

Claim Synopsis: A first component creates modular items with embedded rules for linking/assembly. A second component receives personalization instructions, assembles modular items from various documents based on these rules, and renders the derivative document using an associated style.

---

6. Material & Component Substitution

Derivative 2.1.1: WebAssembly (Wasm) Based Client-Side Assembly Engine

• Enabling Description: The "second component" (content personalization, assembly, and rendering) is largely executed client-side within a web browser, leveraging WebAssembly (Wasm) modules for high-performance rule evaluation and content assembly. The "first component" (content creation) generates modular content items and their associated rules in a format optimized for Wasm consumption. Instead of server-side pulling, the client device prefetches bundles of potential modular items. Personalization instructions trigger the Wasm engine to perform rule-based selection and assembly of these pre-fetched items directly in the browser. Rendering utilizes a highly efficient client-side rendering engine (e.g., WebGL for complex layouts or a custom canvas renderer), ensuring responsiveness and reducing server load. Style application is also handled by Wasm-optimized CSS-in-JS libraries or pre-compiled style sheets.

graph TD
    A[User Input/Context] --> B(Web Browser)
    B -- Wasm Runtime --> C{Client-Side Assembly Engine (Wasm)}
    C -- Rule Evaluation --> D[Pre-fetched Modular Content Bundles]
    D -- Content & Rules (Wasm Optimized) --> E[Client-Side Rendering Engine]
    E -- Dynamic DOM Update --> F[Personalized Document Display]
    C --> E
    Server --> D

Derivative 2.1.2: Holographic Display Rendering with Volumetric Content Modules

• Enabling Description: The "second component" renders derivative documents for holographic displays. "Modular items" are not flat pages but rather volumetric content assets (e.g., 3D models, holographic projections, spatial sound fields). The "first component" (content creation) provides tools for authoring these volumetric assets and embedding rules (e.g., proximity-triggered display, gaze-interaction rules). Personalization instructions might involve holographic positioning, scaling, or interaction modalities. The assembly process dynamically places these volumetric modules in a 3D space, respecting spatial relationships defined by rules and user preferences. Rendering involves a real-time volumetric rendering pipeline optimized for specific holographic display hardware (e.g., light-field displays), ensuring correct parallax and depth perception, and dynamically adjusting the "style" to the display's capabilities and ambient light conditions.

graph TD
    A[User Interaction (Gaze, Gesture)] --> B(Holographic Device Input)
    C[Personalization Instructions] --> B
    B --> D{Volumetric Assembly Engine}
    D -- Rule Evaluation (Spatial, Proximity, Gaze) --> E[Volumetric Content Repository (3D Models, Spatial Audio)]
    E -- Holographic Assets --> D
    D --> F[Real-time Volumetric Renderer]
    F --> G[Holographic Display]

Derivative 2.1.3: Biometric-Authenticated Modular Access and Assembly

• Enabling Description: This system enforces strict access control for modular content items and personalization instructions using biometric authentication. The "first component" securely associates modular items and their rules with biometric identity hashes (e.g., iris scan, fingerprint template). The "second component" receives personalization instructions only after successful multi-factor biometric authentication of the user. The assembly engine then dynamically decrypts and pulls modular items whose associated biometric permissions match the authenticated user's profile. This ensures that only authorized individuals can access and view sensitive personalized content. The "style" of the rendered document may also adapt based on the security level associated with the authenticated biometric profile, e.g., displaying watermarks for high-security content.

sequenceDiagram
    participant U as User
    participant BD as Biometric Device
    participant PC as Personalization Component
    participant AA as Authentication & Authorization
    participant MR as Modular Content Repository
    U->>BD: Biometric Scan
    BD->>AA: Submit Biometric Hash
    AA-->>U: Authentication Success/Fail
    U->>PC: Submit Personalization Request (Authenticated)
    PC->>AA: Request Modular Item Access
    AA-->>MR: Verify Biometric Permissions
    MR-->>AA: Return Authorized Encrypted Modules
    AA-->>PC: Deliver Decrypted Modules
    PC->>PC: Assemble & Render
    PC-->>U: Display Personalized Document

---

7. Operational Parameter Expansion

Derivative 2.2.1: Hyper-Adaptive Semantic Content Graph Assembly

• Enabling Description: This system manages "documents" and "modular items" as nodes and edges within a vast, dynamically evolving semantic knowledge graph containing billions of interlinked content fragments. The "set of rules" for each modular item is expressed as complex SPARQL queries or OWL axioms operating on this graph. The "second component" (assembly) operates at petabyte-scale data volumes, evaluating rule sets with thousands of interwoven logical conditions and contextual relationships (e.g., ontological classifications, temporal dependencies, user interaction history across the entire content ecosystem). The personalization instruction is a high-level intent, which the system then translates into a cascade of semantic queries to assemble a highly granular derivative document. Rendering dynamically adjusts layout and visual hierarchy based on the semantic density and perceived importance of the assembled content, ensuring optimal information flow.

graph TD
    A[High-level User Intent] --> B(Semantic Query Generator)
    B --> C{Petabyte-Scale Semantic Graph (OWL/RDF)}
    C -- SPARQL/OWL Query --> D[Modular Content Nodes]
    D -- Billions of Content Fragments --> C
    C -- Rule-based Traversal & Selection --> E{Hyper-Adaptive Assembly Engine}
    E --> F[Dynamic Layout & Visual Hierarchy]
    F --> G[Derivative Document (Semantic-aware)]
    G --> A

Derivative 2.2.2: Extreme Real-time Haptic Feedback Document Personalization

• Enabling Description: This system creates "interactive documents" that include real-time haptic feedback (e.g., variable textures, vibration patterns, force feedback) as a core part of its personalized experience. "Modular items" can embed haptic profiles (e.g., "rough texture," "smooth slide," "sharp click") alongside visual and textual content. The "set of rules" defines conditions for triggering specific haptic responses based on user interaction (e.g., cursor hover, pressure applied to a touchscreen, VR glove gestures) and personalization parameters (e.g., user's known tactile preferences, accessibility needs). The "second component" processes thousands of haptic feedback events per second, dynamically assembling and synchronizing haptic outputs with visual and audio rendering. The "style" component extends to haptic rendering, adjusting intensity and duration to match the visual presentation, creating a truly multi-sensory personalized document.

sequenceDiagram
    participant U as User (w/ Haptic Device)
    participant CE as Content Event Generator
    participant HE as Haptic Engine
    participant DE as Document Assembly Engine
    participant HC as Haptic Content Store
    U->>CE: Interact (Hover, Touch)
    CE->>HE: Haptic Trigger (Context, Params)
    HE->>HC: Query Haptic Profile (Rules)
    HC-->>HE: Return Haptic Data
    HE->>U: Deliver Haptic Feedback (ms)
    CE->>DE: Update Personalization State
    DE->>DE: Re-assemble/Render (Visual, Audio)
    DE-->>U: Display/Play Content

Derivative 2.2.3: Quantum Annealing Optimized Rule Matching for Massive Personalization Options

• Enabling Description: For "documents" with an astronomically large number of potential "modular items" (e.g., millions of micro-content snippets) and extremely complex, inter-dependent "sets of rules" (e.g., combinatorial conditions across hundreds of personalization parameters), the "second component" utilizes a Quantum Annealing processor (e.g., D-Wave) to solve the NP-hard problem of optimal rule matching and content selection. Personalization instructions are translated into an Ising model or Quadratic Unconstrained Binary Optimization (QUBO) problem. The quantum annealer rapidly finds the ground state, which corresponds to the optimal subset of modular items satisfying the complex rules and personalization constraints. This enables personalization at a scale and complexity currently intractable for classical computers, allowing for truly bespoke derivative documents from vast content libraries.

graph TD
    A[Massive Personalization Params] --> B(Ising/QUBO Model Converter)
    B --> C{Quantum Annealer}
    C -- Finds Ground State --> D[Optimal Modular Item Subset]
    D --> E{Document Assembly Engine}
    E --> F[Massive Modular Content Library]
    F --> E
    E --> G[Hyper-Personalized Derivative Document]

---

8. Cross-Domain Application

Derivative 2.3.1: Smart Cities - Adaptive Public Information Display System

• Enabling Description: This system dynamically generates localized and time-sensitive public information for smart city displays (e.g., digital kiosks, public transit screens). The "first component" allows city planners to create modular information items (e.g., transit route updates, emergency alerts, cultural event listings, air quality reports) with rules based on real-time city data. The "set of rules" for each modular item considers parameters such as current time of day, location of the display, local population density, current traffic conditions, air quality sensor readings, and emergency service alerts. The "second component" receives personalization instructions (implicitly from display location and real-time sensor feeds) and assembles relevant modular items. For instance, during a pollution event, an air quality alert module will supersede cultural event listings. The "style" dynamically adjusts to ambient light conditions and accessibility requirements (e.g., large text for elderly viewers, sign language video for hearing impaired). The derivative document is the real-time content displayed on the public screen.

graph TD
    A[City Sensor Data (Traffic, Air Quality)] --> B(Real-time City Context)
    C[Display Location/Time] --> B
    D[Emergency Alerts] --> B
    B --> E{Public Display Assembly Engine}
    E -- Rule Eval (Location, Time, Emergencies, Sensors) --> F[Modular Public Information (Transit, Events, Alerts)]
    F -- Dynamic Style Adjustment --> E
    E --> G[Adaptive Public Information Display]
    G --> H[City Residents/Visitors]

Derivative 2.3.2: Personalized Education - Adaptive Learning Module Generator

• Enabling Description: This system generates personalized learning modules and curricula for students, adapting to their individual learning styles, pace, and knowledge gaps. The "first component" allows educators to create modular learning units (e.g., video explanations, interactive quizzes, text summaries, problem sets) and embed rules based on pedagogical principles. The "set of rules" for each modular item considers parameters such as student's previous quiz scores, preferred learning modality (e.g., visual, auditory), time spent on a topic, detected frustration levels (e.g., via webcam gaze/emotion analysis), and mastery goals. The "second component" receives personalization instructions (student ID, current topic) and uses the rules to assemble an optimal sequence of learning modules. For example, if a student struggles with a concept, a remedial video explanation module might be inserted. The "style" of the derivative learning path adapts with progress indicators, gamification elements, and visual themes to maintain student engagement.

graph TD
    A[Student Performance Data (Quiz Scores, Time)] --> B(Learning Analytics)
    C[Student Profile (Style, Goals)] --> B
    D[Gaze/Emotion Analysis] --> B
    B --> E{Adaptive Learning Assembly Engine}
    E -- Rule Eval (Scores, Style, Frustration, Goals) --> F[Modular Learning Units (Videos, Quizzes, Text, Problems)]
    F -- Adaptive Style/Gamification --> E
    E --> G[Personalized Learning Path/Module]
    G --> H[Student Device]
    H --> A

Derivative 2.3.3: Manufacturing - Real-time Machine Operator Instruction Assembly

• Enabling Description: This system provides real-time, personalized work instructions for machine operators on a factory floor. The "first component" enables engineers to create modular operational steps (e.g., tool setup, safety checks, component loading sequences, quality control procedures) and embed rules for their display. The "set of rules" for each step considers parameters such as the specific machine model, current production batch, operator's certification level, tool inventory availability, and real-time sensor data from the machine (e.g., temperature, pressure, part count). The "second component" receives personalization instructions (operator ID, machine ID, task) and assembles the most relevant and efficient sequence of instructions. If a sensor indicates an anomaly, an immediate troubleshooting module is inserted. The "style" of the instructions adapts to the industrial environment (e.g., high-contrast, large-font display on a ruggedized tablet or heads-up display) and can incorporate augmented reality overlays for complex tasks.

graph TD
    A[Machine Sensor Data (Temp, Pressure, Count)] --> B(Real-time Production Context)
    C[Operator ID, Machine ID, Task] --> B
    D[Tool/Component Inventory] --> B
    B --> E{Instruction Assembly Engine}
    E -- Rule Eval (Machine, Batch, Operator Cert, Tools, Sensors) --> F[Modular Operational Steps (Setup, Safety, Load, QC)]
    F -- Industrial UI/AR Overlays --> E
    E --> G[Real-time Operator Instructions (Rugged Tablet/HUD)]
    G --> H[Machine Operator]

---

9. Integration with Emerging Tech

Derivative 2.4.1: AI-Generated Content Creation with Human-in-the-Loop Rule Refinement

• Enabling Description: This system uses Generative AI (e.g., Large Language Models, Stable Diffusion) within the "first component" to automatically generate diverse "modular items" (text, images, video snippets) based on high-level prompts. These AI-generated modular items are then automatically tagged with preliminary "sets of rules" derived from semantic analysis of their content. A "human-in-the-loop" mechanism allows content creators to review, modify, and refine these AI-generated rules and modular items. The "second component" receives personalization instructions and uses these (potentially human-refined) AI-generated rules for assembly. Furthermore, the AI can also suggest optimal "styles" based on the derivative document's content and target audience. The system incorporates Reinforcement Learning from Human Feedback (RLHF) to continuously improve the AI's ability to generate relevant content and effective rules.

graph TD
    A[High-level Content Prompt] --> B(Generative AI (LLM, Diffusion))
    B -- AI-generated Content/Rules --> C[Human-in-the-Loop Review/Refinement]
    C --> D[Modular Content/Rule Store]
    D --> E{Personalization & Assembly Engine}
    E --> F[Personalized Derivative Document]
    F -- Reader Feedback --> G(RLHF System)
    G -- Model Improvement --> B

Derivative 2.4.2: IoT-Triggered Context-Aware Adaptive Document Updates

• Enabling Description: This system enables "documents" to automatically update and reassemble their "modular items" based on real-time changes detected by IoT sensors. For example, a "smart product manual" (the derivative document) for an appliance. The "first component" allows authors to create modular troubleshooting steps or feature explanations linked to specific appliance sensor states. The "set of rules" for each modular item is tied directly to IoT data streams (e.g., "if refrigerator door open for >5 min", "if washing machine error code E42"). The "second component" continuously monitors a stream of IoT sensor data (personalization instructions). If a relevant sensor event occurs, the system automatically triggers a re-assembly, pulling appropriate troubleshooting guides or usage tips from other documents. The "style" can include dynamic visual cues (e.g., flashing alert icon) to draw attention to newly inserted content relevant to the IoT event.

graph TD
    A[IoT Sensor Stream (Appliance Diagnostics)] --> B(Real-time Event Detector)
    B --> C{Adaptive Document Assembly Engine}
    C -- Rule Eval (Sensor State, Error Codes) --> D[Modular Troubleshooting/Usage Tips]
    D --> C
    C -- Re-assembles/Updates --> E[Smart Product Manual (Derivative Document)]
    E --> F[User Device/Appliance Display]

Derivative 2.4.3: Decentralized Identity and Verifiable Credential-Based Document Access & Personalization

• Enabling Description: This system uses Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) (e.g., W3C VC Data Model) to manage access to "modular items" and drive personalization. Users possess self-sovereign digital identities and VCs (e.g., "verified employee of Company X," "certified in Skill Y"). The "first component" associates "modular items" and their "sets of rules" with specific credential requirements. The "second component" receives personalization instructions, including presentation of VCs from the user's digital wallet. The assembly engine evaluates rules against these cryptographically verifiable claims. For example, a confidential project report (derivative document) may only assemble specific "modular items" (e.g., sensitive financial data) if the user presents a VC proving "Project Lead" status and "Security Clearance Level 5." The "style" might apply a watermark or digital signature based on the strength of the presented credentials. This ensures robust, privacy-preserving, and tamper-evident authorization for personalized content.

sequenceDiagram
    participant U as User (w/ Digital Wallet)
    participant PC as Personalization Component
    participant AA as VC Verifier
    participant BC as Blockchain/DID Ledger
    participant MR as Modular Content Repository
    U->>PC: Request Document, Present VCs
    PC->>AA: Submit VCs for Verification
    AA->>BC: Verify VC Integrity & Issuer DID
    BC-->>AA: Verification Result
    AA-->>PC: Validated Claims
    PC->>MR: Request Modules (Rules + Claims)
    MR-->>PC: Deliver Authorized Modules
    PC->>PC: Assemble & Render
    PC-->>U: Display Personalized Document

---

Combination Prior Art Scenarios with Open-Source Standards

These scenarios combine the core concepts of US11379651 (modular content, rule-based assembly, personalization, dynamic rendering) with existing open-source standards to demonstrate prior art for broad applicability.

Combination Prior Art 1: Modular Content Assembly with Markdown and Git/Jekyll

• Description: The system utilizes a collection of plain-text "modular items" written in Markdown (an open-source lightweight markup language) stored in a Git repository (an open-source distributed version control system). Each Markdown file (modular item) includes YAML front matter for metadata, where "assembly rules" are defined using a simple key-value structure or a domain-specific language (DSL). A static site generator like Jekyll (an open-source Ruby-based framework) acts as the "assembly engine." Personalization parameters are provided via command-line flags or environment variables during the build process, or through client-side JavaScript injected into the static HTML. Jekyll's templating engine (Liquid) processes the rules and metadata, dynamically selecting and assembling Markdown files into a "derivative document" (e.g., a personalized report, a website page). The "style" is controlled by open-source CSS frameworks (e.g., Bootstrap) applied to the Jekyll templates. This demonstrates modular content creation, rule embedding, parameter-driven pulling and assembly, and rendering using widely available open-source tools.
• Open-Source Standards: Markdown, Git, Jekyll, YAML, Liquid, Bootstrap.

graph TD
    A[Content Creator (Markdown + YAML)] --> B(Git Repository)
    B --> C{Jekyll Build Process (Assembly Engine)}
    D[Personalization Parameters (CLI/Env Vars)] --> C
    C -- Rule Evaluation (YAML Front Matter) --> B
    B -- Pulls Markdown Files --> C
    C -- Templating (Liquid) --> E[Static HTML/CSS Files]
    E --> F[Web Browser (Derivative Document)]

Combination Prior Art 2: Dynamic Document Generation with XML/XSLT and OpenDocument Format (ODF)

• Description: This system focuses on structured document personalization using XML and XSLT (eXtensible Stylesheet Language Transformations), generating documents in the OpenDocument Format (ODF). "Modular items" are defined as XML fragments conforming to a specific schema (e.g., DITA XML topics or custom XML structures), each containing embedded "assembly rules" as XPath expressions or XSLT templates. These modular items are stored in an XML database (e.g., BaseX, eXist-db). Personalization parameters are provided as XML input documents or parameters to an XSLT processor. The "assembly engine" is an XSLT 2.0/3.0 processor that takes a master XML document (the "first document") and the personalization parameters, then applies XSLT stylesheets that use XPath to evaluate rules and pull relevant XML modular items from the database. The output "derivative document" is a well-formed ODF (e.g., .odt, .ods) document, where the "style" is defined by embedded ODF styles or through further XSLT transformations targeting ODF's internal XML structure. This showcases rule-based assembly of structured content into standard, open formats.
• Open-Source Standards: XML, XSLT, XPath, OpenDocument Format (ODF), DITA XML.

graph TD
    A[Content Creator (XML Fragments)] --> B(XML Database)
    B -- DITA/Custom Schema --> C{XSLT Processor (Assembly Engine)}
    D[Personalization Parameters (XML)] --> C
    C -- XPath Rule Eval --> B
    B -- Pulls XML Modules --> C
    C -- XSLT Transformation --> E[OpenDocument Format (ODF) File]
    E --> F[ODF Viewer (Derivative Document)]

Combination Prior Art 3: Micro-Frontend Based Content Personalization with React and GraphQL

• Description: This system implements personalization using a "micro-frontend" architecture where each "modular item" is a distinct, independently deployable React component (an open-source JavaScript library). These components are registered in a central registry with associated "assembly rules" defined as component props or GraphQL directives. The "first document" is a top-level React application that dynamically loads these micro-frontends. Personalization parameters are received via a GraphQL API (an open-source query language) from the client device. The "assembly engine" is a client-side JavaScript module that, based on GraphQL query results and component rules, orchestrates the dynamic loading and rendering of relevant React micro-frontend components. The "derivative document" is the single-page application experience, dynamically composed of personalized micro-frontends. The "style" is managed using open-source CSS-in-JS libraries (e.g., Styled Components, Emotion) or utility-first CSS frameworks (e.g., Tailwind CSS) within each component, ensuring consistent branding across dynamically assembled content.
• Open-Source Standards: React, GraphQL, Micro-frontends (architectural pattern), CSS-in-JS (e.g., Styled Components), Tailwind CSS.

graph TD
    A[User Device/Client App] --> B(GraphQL API Gateway)
    B -- Personalization Params --> C{Client-Side Assembly Module (JS)}
    C -- GraphQL Query --> B
    B -- Component Registry/Rules --> C
    C -- Dynamically Loads --> D[React Micro-Frontend Components]
    D -- Rendered --> E[Personalized SPA (Derivative Document)]
    E --> A